Pętla zwrotna do przekazanego publicznego adresu IP z sieci lokalnej - Hairpin NAT

To jest kanoniczne pytanie dotyczące Hairpin NAT (Loopback NAT).

Ogólna forma tego pytania brzmi:

Mamy sieć z klientami, serwer i router NAT. Na routerze jest przekierowanie portów na serwer, więc niektóre z jego usług są dostępne zewnętrznie. Mamy DNS wskazujący na zewnętrzny adres IP. Klienci sieci lokalnej nie mogą się połączyć, ale działają zewnętrzne.

• Dlaczego to się nie udaje?
• Jak mogę stworzyć ujednolicony schemat nazewnictwa (nazwy DNS, które działają zarówno lokalnie, jak i zewnętrznie)?

To pytanie zostało połączone z wielu innych pytań. Początkowo odnosiły się do FreeBSD, D-Link, Microtik i innych urządzeń. Wszyscy jednak próbują rozwiązać ten sam problem.

To, czego szukasz, nazywa się „spinką do włosów NAT”. Żądania z interfejsu wewnętrznego adresu IP przypisanego do interfejsu zewnętrznego powinny być NAT'owane tak, jakby przychodziły z interfejsu strony zewnętrznej.

W ogóle nie znam znajomości FreeBSD, ale czytam instrukcję „pf” dla OpenBSD ( http://www.openbsd.org/faq/pf/rdr.html ) proponowanych rozwiązań DNS z dzielonym horyzontem, używając Sieć DMZ lub proxy proxy prowadzą mnie do przekonania, że ​​„pf” nie obsługuje NAT-spinki do włosów.

Spojrzałbym na wybranie trasy DNS z rozłożonym horyzontem i nieużywanie adresów IP w adresach URL wewnętrznie, ale zamiast używania nazw.

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.

Problem polega na tym, że router nie ma adresu NAT adresu wewnętrznego klienta. Dlatego uzgadnianie TCP kończy się niepowodzeniem.

Załóżmy następujące adresy IP

• Klient: 192.168.1.3
• Serwer: 192.168.1.2
• Router wewnętrzny: 192.168.1
• Router zewnętrzny: 123.123.123.1

Oto co się dzieje:

1. Klient (192.168.1.3) wysyła TCP-SYN na zewnętrzny adres IP portu 80 (123.123.123.1:80)
2. Router widzi regułę przekierowania portów i przekazuje pakiet do serwera (192.168.1.2:80) bez zmiany źródłowego adresu IP (192.168.1.3)
3. Klient czeka na SYN-ACK z zewnętrznego adresu IP
4. Serwer odsyła odpowiedź bezpośrednio do klienta, ponieważ jest on w tej samej podsieci. Nie wysyła pakietu do routera, który odwróciłby NAT.
5. Klient otrzymuje SYN-ACK z 192.168.1.2 zamiast 123.123.123.1. I odrzuca to.
6. Klient nadal czeka na SYN-ACK od 123.123.123.1 i kończy limit czasu.

Dlaczego nie używać wszędzie podzielonych horyzontów DNS zamiast twardych adresów IP? Miałbyś ext. Twoja domena wskazująca na 217.xxx na zewnątrz, a następnie 192.xxx wewnątrz.

Jeśli jest to oryginalny router D-Link (tj. Nie Rev. D / Firmware wersja 1.00VG z Virgin Media), powinieneś być w stanie dostosować ustawienia, aby obejść ten problem. (Zgadzam się jednak z sugestią DD-WRT poprzedniego autora z wielu innych powodów!)

1. Zaloguj się do interfejsu internetowego routera
2. Kliknij kartę Zaawansowane u góry
3. Kliknij kartę Ustawienia zapory po lewej stronie
4. Kliknij przycisk radiowy Niezależny punkt końcowy w obszarze Filtrowanie punktu końcowego TCP , jak pokazano na zrzucie ekranu poniżej (lub zobacz emulator routera na stronie D-Link)
5. Zapisz zmiany; Jesteś skończony

Ten zrzut ekranu pochodzi z modelu Rev. C; twój może być nieco inny.

Ostatnio odpowiedziałem na podobne pytanie: statyczny NAT Cisco nie działa po stronie sieci LAN i właśnie zdałem sobie sprawę, że jest to pytanie kanoniczne. Pozwólcie, że streszczę tutaj rozwiązanie.

Po pierwsze: zapomnij o NAT (jeśli możesz) - w ogóle nie chodzi o konfigurację NAT. Chodzi o dostęp do serwera umieszczonego za NAT zarówno z Internetu, jak i LAN. Zastosowanie dwóch stref DNS jest realną alternatywą, ale nie zawsze rozwiązaniem. Ale rozwiązanie istnieje i jest niezwykle proste (choć prawdopodobnie nie idealne):

(1) na serwerze: dodaj publiczny adres IP jako dodatkowy adres IP w interfejsie sieciowym serwera za pomocą maski 255.255.255.255 (usługa internetowa lub cokolwiek chcesz na serwerze, powinno nasłuchiwać również na tym adresie IP); wszystkie nowoczesne systemy operacyjne pozwolą ci to zrobić (lub zamiast dodania drugiego adresu IP do interfejsu podstawowego można użyć interfejsu sprzężenia zwrotnego z przypisanym do niego publicznym adresem IP).

(2) na hostach LAN: dodaj trasę hosta dla publicznego adresu IP, na przykład dla hostów Windows użyj następującej komendy: route -p dodaj 203.0.113.130 mask 255.255.255.255 192.168.1.11 (możesz również użyć DHCP ” trasa statyczna ”, aby rozdzielić trasę). Lub, jeśli między klientami a routerem internetowym znajduje się (a) przełącznik (-y) L3 / router (y), skonfiguruj trasę hosta na tym (tych) przełącznikach / routerach pośrednich, a nie na klientach.

Dla osób zainteresowanych potrójnym uzgadnianiem TCP: będzie działać OK w proponowanej konfiguracji.

Prześlij opinię (przynajmniej głosuj).

Zła odpowiedź na moje pytania, aby poszerzyć horyzonty dla osób z podobnymi problemami.

Skontaktowano się z moim dostawcą usług internetowych i poprosiłem go, aby spróbował rozwiązać moje problemy. To, co mi zaoferowali, to inny publiczny adres IP tylko dla serwera. Teraz mam ruch lokalny po stronie WAN FreeBSD i stworzyliśmy specjalne potoki dla szybszej przepustowości lokalnego ruchu do publicznego adresu IP serwera

Z technicznego punktu widzenia najlepszym rozwiązaniem tego problemu jest włączenie IPv6 w sieci. Gdy protokół IPv6 jest włączony, musisz utworzyć rekord AAAA dla swojej domeny. Zachowaj istniejący rekord A wskazujący na zewnętrzny IPv4 routera . Utwórz rekord AAAA wskazujący na adres IPv6 serwera .

IPv6 ma wystarczającą liczbę adresów, aby uniknąć translacji NAT, więc nie będziesz potrzebować translacji NAT dla IPv6. Po włączeniu protokołu IPv6 i utworzeniu rekordów AAAA każdy klient obsługujący standard RFC 8305 wypróbuje protokół IPv6 przed IPv4. Oznacza to, że nie potrzebujesz też spinki do włosów dla IPv4, ponieważ klienci nie będą jej używać.

Nadal będziesz potrzebować istniejącego NAT IPv4 dla połączeń wychodzących i przekierowania portów dla połączeń przychodzących, dopóki większość świata nie włączy również IPv6.

Jest też szybszy.

Korzystanie z IPv6 zapewni lepszą wydajność niż NAT-spinka do włosów.

Dzięki hairpin NAT twój klient wyśle ​​pakiet przez przełącznik do routera, router następnie wykona dwie rundy tłumaczenia i ostatecznie wyśle ​​pakiet przez przełącznik do serwera. Pakiety z serwera do klienta przechodzą przez całą ścieżkę w odwrotnej kolejności.

Dzięki IPv6 unikasz NAT, zamiast tego pakiety są wysyłane bezpośrednio przez przełącznik między klientem a serwerem. Oznacza to, że podczas podróży w obie strony zmniejszasz liczbę przejść przez przełącznik z 4 do 2 i unikasz 2 podróży przez router i 4 tłumaczeń, które wykonałby router. Przekłada się to na lepszą wydajność.

Jest to prawdą, nawet jeśli używasz przełącznika wbudowanego w to samo urządzenie co router.

Co jeśli dostawca usług internetowych nie ma IPv6?

Jeśli używasz usługodawcy internetowego, który nie obsługuje protokołu IPv6, zapytam, czy powinieneś hostować serwery w tej sieci. To są moje sugestie, co zrobić, jeśli dostawca usług internetowych nie obsługuje obecnie protokołu IPv6.

Najpierw powiedz dostawcy usług internetowych, że potrzebujesz IPv6. A może przypomnieć im, że protokół IPv6 istnieje już od 20 lat, więc od dawna go obsługują. Jeśli to nie wystarczy, aby dostawca usług internetowych wziął cię na poważnie, zacznij szukać innych dostawców usług internetowych.

Jeśli znajdziesz usługodawcę internetowego obsługującego protokół IPv6, możesz korzystać z niego przez okres przejściowy. Na routerze podłączonym do nowego dostawcy usług internetowych możesz wyłączyć IPv4 po stronie LAN, a następnie podłączyć strony LAN obu routerów do tego samego przełącznika. IPv4 i IPv6 to dwa niezależne protokoły i jako takie nie stanowi żadnego problemu, jeśli połączenia te przechodzą przez różne routery. Dodatkową korzyścią jest pewna nadmiarowość, jeśli jedno z połączeń ma awarię.

Jeśli nie możesz znaleźć usługodawcy internetowego obsługującego protokół IPv6, powinieneś rozważyć przeniesienie serwera do hostingu. Dzięki serwerowi w obiekcie hostingowym jesteś mniej zależny od lokalizacji geograficznej, dlatego między dostawcami jest większa konkurencja, która pomoże zapewnić taki, który zaspokoi twoje potrzeby.

Przeniesienie serwera do obiektu hostingowego nie da klientom IPv6, ale przeniesienie serwera oznacza, że ​​nie jest już potrzebny do tego dostęp do translacji NAT.

Czego nie powinieneś robić

Nie włączaj IPv6 i nie twórz rekordów AAAA, jeśli nie masz sposobu na skierowanie ruchu IPv6. Jeśli twój dostawca usług internetowych nie obsługuje IPv6, ale mimo to zdecydujesz się włączyć IPv6 w twojej sieci LAN (być może przy użyciu adresów RFC 4193) i utworzyć rekordy AAAA, będzie działać dla klientów w twojej sieci LAN, którzy docierają do serwera w twojej sieci LAN. Ale komunikacja między twoją siecią LAN a światem zewnętrznym najpierw spróbowałaby IPv6 (który nie działałby), a ty polegałbyś na powrocie do IPv4, który w najlepszym razie jest trochę wolniejszy lub w najgorszym przypadku nie.

Ponieważ zadałem również to pytanie (zobacz Jak uzyskać dostęp do usługi sieciowej NATed za zaporą wewnętrzną za pomocą jej zewnętrznego adresu IP? ) I zostałem przekierowany tutaj, ale odpowiedzi tutaj nie zapewniły rozwiązania (w przeciwieństwie do ogólnych wyjaśnień ) podaj tutaj moje ( iptablesspecyficzne) rozwiązanie dla systemu Linux , aby zaoszczędzić wszystkim kilka godzin eksperymentów. Ten plik ma iptables-restoreformat i można go wczytać bezpośrednio do iptables (oczywiście po edycji adresów IP). Dotyczy to serwera WWW (port 80) i tylko IPv4 - zasady dla IPv6 i SSL (port 443) są analogiczne.

# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Zastąpić lan.local, web.locala web.public.comz sieci lokalnej (np. 10.0.x.0 / 24), na serwer za lokalny IP (np 10.0.1.2) i routera publiczny adres IP (np. 4.5.6.7). Ma -4to na celu zezwolenie na reguły IPv6 i IPv4 w tym samym pliku (takie linie są ignorowane przez ip6tables). Pamiętaj również, aby umieszczać adresy IPv6 w [nawiasach], gdy zawierają deklaracje portów, np [fe0a:bd52::2]:80.

Były to wszystko rzeczy, które spowodowały, że ciągnąć moje włosy podczas próby rzeczywiście wdrożyć wyjaśnień w tej kwestii. Mam nadzieję, że nic nie pominąłem.

Dodam tutaj odpowiedź, ponieważ komentarze tutaj nie rozwiązały mojego konkretnego problemu. Podejrzewam, że to dlatego, że trafiłem w nieprzyjemny błąd jądra Linuksa. Konfiguracja jest następująca:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

Pomimo złożonego obrazu jedyną istotną zmianą w sytuacjach opisanych w innych komentarzach jest dodanie mostka programowego, br0. Jest tam, ponieważ brama jest także bezprzewodowym punktem dostępu do sieci LAN.

Nasz moduł bramy nadal wykonuje obowiązki NAT dla maszyn w sieci LAN. Ponieważ ma tylko 1 port ethernetowy, jest zmuszony wykonać NAT. Podejrzewam, że powinien po prostu działać z regułami iptables podanymi w innych komentarzach tutaj, ale w jądrze Linuksa 4.9 przynajmniej tak nie jest. Poniżej wersji 4.9 nasze pole bramkowe może uzyskać dostęp do Internetu, a maszyny w sieci LAN próbujące uzyskać do niego dostęp za pośrednictwem NAT nie mogą.

tcpdumppokazuje odpowiedzi na przychodzące pakiety uderzające w eth0, ale nie robią tego z br0. Uruchomienie tego polecenia naprawia:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

Przed uruchomieniem tej komendy przychodzące pakiety są przetwarzane zgodnie z domyślnym zachowaniem jądra, które polega na przekazaniu ich do mostu, a następnie przekazaniu ich modułom routingu jądra. Polecenie zmusza pakiety, które nie są z sieci LAN, do ominięcia mostu i przejścia bezpośrednio do routingu, co oznacza, że ​​most nie ma szansy ich upuścić. Adresy rozgłoszeniowe i multiemisji muszą być zmostkowane, w przeciwnym razie takie rzeczy jak DHCP i mDNS nie będą działać. jeśli używasz IPv6, musisz również dodać dla niego reguły.

Możesz ulec pokusie rozwiązania problemu za pomocą tego:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

Z pewnością byłem tak kuszony - to była moja pierwsza próba. Jak tylko to zrobiłem, maszyny w sieci LAN uzyskały dostęp do Internetu, więc działa przez chwilę. Potem miały miejsce następujące zdarzenia (i nie chciałem powtarzać eksperymentu):

1. Czasy pingowania przez LAN do bramki podwajały się w około 10 sekundowych odstępach, zwiększając się z 0,1 ms do 0,2 ms, 0,4 ms, 0,8 ms, 2 ms i tak dalej, aż skrzynka bramy była niedostępna z sieci LAN. Pachniało jak burza pakietowa, ale STP był włączony wszędzie.
2. Niedługo po śmierci wszystkich bezprzewodowych punktów dostępowych.
3. Podczas próby zdiagnozowania, co się dzieje z siecią bezprzewodową, wszystkie telefony IP uruchomiły się ponownie.
4. Niedługo potem maszyny przewodowe straciły kontakt z siecią LAN.

Jedynym wyjściem było ponowne uruchomienie każdej maszyny w budynku. Jedynym wyjątkiem były przełączniki sprzętowe, których nie można zrestartować. Musiały być zasilane cyklicznie.

Ponieważ jest to pytanie kanoniczne. Odpowiem, jeśli masz router Sonicwall.

Wyrażeniem, które należy znać, jest zasada sprzężenia zwrotnego NAT

W tym dokumencie opisano, w jaki sposób host w sieci SonicWall LAN może uzyskać dostęp do serwera w sieci SonicWall LAN, używając publicznego adresu IP serwera do FQDN. Wyobraź sobie sieć NSA 4500 (SonicOS Enhanced), w której podstawowa podsieć LAN to 10.100.0.0 / 24, a podstawowa sieć WAN IP to 3.3.2.1. Załóżmy, że masz witrynę internetową dla swoich klientów, a jej nazwa hosta to. Napisałeś już niezbędne zasady i reguły, aby osoby z zewnątrz mogły dostać się na stronę internetową, ale tak naprawdę działa ona na prywatnym serwerze 10.100.0.2. Teraz wyobraź sobie, że jesteś osobą korzystającą z laptopa po stronie prywatnej, z adresem IP 10.100.0.200. Chcesz dotrzeć do serwera, używając jego publicznej nazwy, ponieważ robisz to samo, gdy laptop jest z tobą w drodze. Jeśli siedzisz po stronie prywatnej i poprosisz o http://www.example.com>, funkcja sprzężenia zwrotnego umożliwia to, nawet jeśli serwer znajduje się tuż obok ciebie na lokalnym adresie IP.

Aby umożliwić tę funkcję, należy utworzyć zasadę sprzężenia zwrotnego NAT, znaną również jako odbicie NAT lub spinka do włosów.

Zasady sprzężenia zwrotnego przy użyciu adresu IP interfejsu WAN

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

Sonicwall rozpozna usługę zewnętrzną, z którą próbujesz się skontaktować, i przepisze adres docelowy, aby pasował do wewnętrznego adresu serwera, dzięki czemu będzie przezroczysty dla komputera.

W FreeBSD przy użyciu PF jest to łatwe, ponieważ (w pliku pf.conf):

extif = "tun0"
intif = "em0"
{other rules}...
nat on $intif from any to 192.168.20.8 port 80 -> ($extif)

192.168.20.8 byłby wewnętrznym serwerem WWW.