Hairpin NAT: dlaczego punkt końcowy VPN zawodzi od wewnątrz

Serwer VPN, który odpowiada z sieci komórkowej, a zawodzi z kanapy, zwykle nie jest problemem certyfikatu. Klient wewnątrz LAN prosi router o przetłumaczenie pakietu, którego celem jest własny publiczny adres routera, co oznacza, że pakiet musi wyjść i od razu wrócić do środka. Ten manewr nazywa się hairpinning, a wiele routerów albo go nie implementuje, albo robi to tylko po zaznaczeniu pola. Właśnie udany test z zewnątrz wprowadza zamieszanie, bo dowodzi, że nasłuch i reguła przekierowania są w porządku.

Pakiet wychodzi i wraca do środka

Prześledź pakiet. Klient rozwiązuje publiczną nazwę, łączy się z publicznym adresem, a NAT docelowy routera przepisuje cel na wewnętrzny serwer. Odpowiedź serwera jest zaadresowana do adresu LAN klienta, więc wraca przez interfejs LAN routera, nigdy nie przechodząc przez regułę NAT, która przetłumaczyłaby źródło z powrotem.

Teraz klient otrzymuje pakiet z adresu, do którego nigdy nic nie wysłał, i odrzuca go. Ta asymetria to cała usterka.

RFC 4787 opisuje zachowanie oczekiwane od NAT w tym przypadku, a krótka wersja jest taka, że w praktyce jest ono opcjonalne, nawet tam gdzie jest określone teoretycznie. Niektóre routery nazywają to ustawienie NAT loopback, inne hairpin NAT lub NAT reflection, a niektóre nie pokazują niczego. Router, który tego nie ma, nie jest źle skonfigurowany; robi rzecz zwyczajną, a poprawka należy gdzie indziej. Nie wyciągaj z nieudanego testu lokalnego wniosku, że publiczna reguła przekierowania jest błędna.

Sprawdzenie 1: przetestuj dwie ścieżki osobno

Spoza LAN połącz się tym samym profilem, którego użyłby prawdziwy użytkownik, i potwierdź, że sesja się nawiązuje. Od wewnątrz połącz się z publicznym adresem tym samym profilem i zapisz dokładny błąd oraz czas.

Dokładny test lokalny zachowuje nazwę hosta i podmienia tylko adres: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ wysyła żądanie na publiczny adres, wciąż przedstawiając prawidłową nazwę serwera. To oddziela problem rozwiązywania nazw od problemu tłumaczenia, które łatwo pomylić, gdy ta sama nazwa działa z kawiarni. Zanotuj, czy klient zawodzi na połączeniu TCP, czy później na TLS, bo pierwsze wskazuje tłumaczenie, a drugie tożsamość.

Sprawdzenie 2: przeczytaj, co widzi serwer

Najbardziej użyteczną obserwacją jest widok serwera. Uruchom przechwytywanie na hoście VPN filtrowane po adresie LAN klienta i po adresie LAN routera, a następnie powtórz próbę lokalną. Jeśli nic nie dotrze, pakiet nie przetrwał tłumaczenia.

Jeśli połączenie przychodzi z adresu LAN routera, a nie klienta, trwa hairpinning i źródło zostało przepisane. To działająca konfiguracja, nie usterka.

Sprawdzenie 3: napraw bez dotykania ścieżki zewnętrznej

Istnieją trzy obsługiwane formy, w rosnącej kolejności zasięgu. Najwęższa to dzielony DNS: opublikuj wewnętrzny rekord, aby ta sama nazwa serwera rozwiązywała się na adres wewnętrzny dla klientów w LAN, co całkowicie omija ścieżkę publiczną. Następna to włączenie udokumentowanej opcji loopback lub reflection routera, jeśli ją ma, i zastosowanie jej tylko do tej usługi. Najszersza to reguła source-NAT na routerze, która przepisuje ruch z LAN na serwer, aby odpowiedź wracała przez router; na routerze Linux to reguła MASQUERADE w POSTROUTING, dopasowana do adresu i portu serwera. Wszystkie trzy zostawiają zewnętrzną ścieżkę nietkniętą i to jest właściwość, którą trzeba zachować.

Nie rozszerzaj niepowiązanego przekierowania portów, aby ścieżka lokalna przypominała zewnętrzną, i nie przenoś usługi na inny port, aby obejść problem. Obie zmiany zmieniają, do czego może dotrzeć świat zewnętrzny, aby naprawić coś, co widzi tylko świat wewnętrzny.

Dzielony DNS ma jedną pułapkę, którą warto nazwać. Zastąpienie nazwy hosta dowolnym IP zmienia to, co klient weryfikuje, więc wewnętrzny rekord nadal musi pasować do nazwy w certyfikacie.

Sprawdzenie 4: potem zweryfikuj obie ścieżki

Powtórz próbę zewnętrzną spoza LAN, powtórz próbę wewnętrzną tym samym profilem i potwierdź, że dziennik serwera pokazuje dwie odrębne udane sesje, a nie jeden sukces i jedną ciszę. Następnie sprawdź, czy inni klienci nadal docierają do nasłuchu i czy trasy do prywatnych zasobów się nie zmieniły.

Prowadź krótki zapis: jakiego adresu użył każdy klient, co widział serwer i która z trzech poprawek została zastosowana. Wymagania hairpinningu z RFC 4787 są tu punktem odniesienia dla tego, czego oczekuje się od NAT, i wyjaśniają, dlaczego router bez tej funkcji zachowuje się normalnie. Lokalna awaria, której świat zewnętrzny nie potrafi odtworzyć, jest kwestią tłumaczenia, dopóki nie zostanie dowiedzione inaczej, więc testuj ją jako taką.