Ponieważ zostało to podniesione do rangi kanonicznego pytania na temat spinki do włosów NAT , pomyślałem, że prawdopodobnie powinna mieć odpowiedź bardziej ogólnie poprawną niż obecnie akceptowana, która (choć doskonała) dotyczy konkretnie FreeBSD.
To pytanie dotyczy usług świadczonych przez serwery w sieciach IPv4 zaadresowanych do RFC1918, które są udostępniane użytkownikom zewnętrznym poprzez wprowadzenie docelowego NAT (DNAT) w bramie. Użytkownicy wewnętrzni następnie próbują uzyskać dostęp do tych usług za pośrednictwem adresu zewnętrznego. Ich pakiet wychodzi od klienta do urządzenia bramy, które przepisuje adres docelowy i natychmiast wstrzykuje go z powrotem do sieci wewnętrznej. To właśnie ten ostry zakręt, jaki pakiet wykonuje w bramie, daje początek nazwie spinki do włosów NAT , analogicznie do skrętu spinki do włosów .
Problem pojawia się, gdy urządzenie bramy przepisuje adres docelowy, ale nie adres źródłowy. Serwer następnie otrzymuje pakiet z wewnętrznym adresem docelowym (własnym) i wewnętrznym adresem źródłowym (klienta); wie, że może odpowiedzieć bezpośrednio na taki adres, więc robi to. Ponieważ odpowiedź ta jest bezpośrednia, nie przechodzi ona przez bramę, która nigdy nie ma szansy na zrównoważenie wpływu przychodzącej docelowej translacji adresów sieciowych na pakiet początkowy poprzez przepisanie adresu źródłowego pakietu zwrotnego.
W ten sposób klient wysyła pakiet na zewnętrzny adres IP, ale otrzymuje odpowiedź z wewnętrznego adresu IP. Nie ma pojęcia, że dwa pakiety są częścią tej samej konwersacji, więc rozmowa się nie dzieje.
Rozwiązaniem jest to, że dla pakietów, które wymagają takiego docelowego NAT i które docierają do bramy z sieci wewnętrznej , również wykonują źródłowy NAT (SNAT) na pakiecie przychodzącym, zwykle przez przepisanie adresu źródłowego na adres bramy. Serwer następnie myśli, że klient jest samą bramą i odpowiada bezpośrednio na nią. To z kolei daje bramie szansę na zrównoważenie wpływu DNAT i SNAT na pakiet przychodzący poprzez przepisanie adresów źródłowych i docelowych na pakiecie zwrotnym.
Klient myśli, że rozmawia z zewnętrznym serwerem. Serwer myśli, że rozmawia z urządzeniem bramy. Wszystkie strony są szczęśliwe. W tym momencie pomocny może być schemat:
Niektóre urządzenia bramy klienta są wystarczająco jasne, aby rozpoznać te pakiety, dla których potrzebny jest drugi krok NAT, i prawdopodobnie będą one działać natychmiast po wyjęciu z pudełka w scenariuszu NAT z serpentyną. Inne nie są, a więc nie, i jest mało prawdopodobne, że można je zmusić do pracy. Dyskusja na temat urządzeń klasy konsumenckiej, która jest nie na temat błędu serwera.
Właściwe urządzenia sieciowe można na ogół powiedzieć, aby działały, ale - ponieważ nie zajmują się odgadywaniem swoich administratorów - trzeba im to powiedzieć. Linux używa iptablesDNAT w ten sposób:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11
który włączy prosty DNAT dla portu HTTP do wewnętrznego serwera na 192.168.3.11. Ale aby włączyć NAT typu spinka do włosów, potrzebna byłaby również taka zasada:
iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE
Należy pamiętać, że takie reguły muszą znajdować się we właściwym miejscu w odpowiednich łańcuchach, aby działać poprawnie, aw zależności od ustawień w filterłańcuchu mogą być potrzebne dodatkowe reguły, aby umożliwić przepływ ruchu NATted. Wszystkie takie dyskusje są poza zakresem tej odpowiedzi.
Ale, jak powiedzieli inni, prawidłowo włączająca NAT spinka do włosów nie jest najlepszym sposobem na rozwiązanie problemu. Najlepszym rozwiązaniem jest DNS z podziałem horyzontu , w którym Twoja organizacja podaje różne odpowiedzi dla pierwotnego wyszukiwania, w zależności od tego, gdzie znajduje się klient żądający, albo przez posiadanie różnych serwerów fizycznych dla użytkowników wewnętrznych i zewnętrznych, lub przez skonfigurowanie serwera DNS, aby reagował inaczej zgodnie z adres klienta żądającego.
