Podwójny NAT i Twój VPN: klient działa, serwer nie

Dwa routery tłumaczące adresy rzadko zatrzymują wychodzącego klienta VPN. Hostowanie serwera za nimi jest trudniejsze, zwłaszcza gdy zewnętrzna warstwa to NAT klasy operatorskiej.

Twój router stoi za innym routerem, adres WAN jest prywatny, a klient VPN i tak się łączy. Ta kombinacja zaskakuje ludzi, którzy oczekują, że podwójny NAT zepsuje tunele, ale właśnie połączenia wychodzące tłumaczenie obsługuje najlepiej. Hostowanie serwera VPN za tymi samymi dwiema warstwami to przypadek, który zwykle zawodzi. Narysuj kierunek połączenia, zanim cokolwiek zmienisz.

Najpierw narysuj kierunek połączenia

Otwórz stronę statusu wewnętrznego routera i zapisz jego adres WAN, a następnie porównaj go z adresem, który podaje Ci dowolna usługa publiczna. Jeśli oba się różnią, między Twoim routerem a internetem stoi co najmniej jeden tłumacz. Jeśli adres WAN mieści się w 100.64.0.0/10, zewnętrzny tłumacz prawdopodobnie należy do Twojego dostawcy i nie masz nad nim kontroli. Te dwa fakty decydują, który z kolejnych kroków może w ogóle zadziałać.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

Podwójny NAT to nie podwójny VPN. Tłumaczenie przepisuje adresy i porty; nie dodaje drugiego szyfrowanego tunelu i niczego nie szyfruje. Odróżnianie tych dwóch pojęć jest ważne, bo rozwiązania są zupełnie inne, a jedno z nich wymaga rozmowy z dostawcą, a nie strony ustawień.

Wychodząco: klient pyta, tłumacze mapują

Tunel wychodzący zaczyna się od pakietu z Twojej maszyny, więc każdy tłumacz może utworzyć mapowanie i wpuścić odpowiedź z powrotem. Protokół, port i liczniki bezczynności decydują, czy to mapowanie przetrwa wystarczająco długo, by było użyteczne. Większość routerów konsumenckich radzi sobie z tym bez żadnej konfiguracji.

Awarie, które faktycznie występują, dotyczą zwykle limitów czasu i obsługi protokołów, a nie liczby routerów. Tunel, który pada po kilku minutach ciszy, to wygasające mapowanie, a keepalive jest standardową odpowiedzią. IPsec ma standardowe rozszerzenia NAT-traversal, więc twierdzenie, że nie może przekroczyć tłumaczenia, jest po prostu błędne. Jeśli tunel w ogóle się nie zestawia, przyjrzyj się punktowi końcowemu i danym logowania, zanim obwinisz topologię.

wg show
ping -c3 10.8.0.1

Zatrzymaj się, jeśli tunel wychodzący działa z jednej sieci, a z innej nie. To porównanie dotyczy sieci, a nie liczby routerów.

Przychodząco: przekierowanie obejmuje tylko sprzęt, który posiadasz

Hostowanie serwera to kierunek odwrotny: nowe połączenie przychodzi z internetu i musi dotrzeć do Twojej maszyny przez każdą warstwę. Reguła przekierowania portu na wewnętrznym routerze pomaga tylko wtedy, gdy zewnętrzny tłumacz również dostarcza ten ruch do Ciebie. Powtarzanie lokalnej reguły nie daje kontroli nad sprzętem dostawcy.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Porównaj adres WAN wewnętrznego routera z zaobserwowanym adresem publicznym i zapisz, skąd pochodzi każda wartość. Jeśli adres WAN jest prywatny lub w zakresie współdzielonym, zewnętrzna warstwa wykonuje tłumaczenie, którego nie możesz skonfigurować. Zapytaj dostawcę, jakie przychodzące osiągalności obsługuje, zanim spędzisz cały wieczór na regułach, które nie mogą wejść w życie. Usunięcie routera lub szerokie wyłączenie zapory nie jest diagnozą i jest złą wymianą za jeden otwarty port.

Zatrzymaj się, jeśli zewnętrzna warstwa należy do dostawcy i nie przekazuje. Wtedy obsługiwanymi odpowiedziami są inna metoda dostępu lub przekaźnik, a nie kolejna reguła po Twojej stronie.

Testuj jedną zmienną naraz

Zmieniaj jedną rzecz na test i zapisuj wynik, bo ścieżka z podwójnym NAT ma więcej zmiennych niż ścieżka z jednym routerem. Utrzymuj profil i urządzenie w stałej konfiguracji, a potem porównaj inną sieć dostępu. Zwróć uwagę, czy negocjacja zawodzi, czy sesja pada po bezczynności, czy zawodzą tylko cele prywatne. Te trzy obserwacje wskazują na trzy różne warstwy.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Nakładające się prywatne podsieci to osobna pułapka, której nie naprawi żadna ilość tłumaczenia. Jeśli Twoja sieć domowa i sieć zdalna używają tego samego zakresu, konflikt tras pojawi się niezależnie od tego, ile tłumaczy stoi pomiędzy. Przenumerowanie jednej strony to jedyna trwała odpowiedź.

Zdalna brama zasługuje na taką samą uwagę, bo jej reguły przekierowania i trasy powrotne mogą być brakującym elementem. Tunel, który się uwierzytelnia, nadal może nie mieć użytecznej ścieżki aplikacji, a ta awaria wygląda z perspektywy klienta identycznie. Przewodnik kończy się, gdy potrafisz powiedzieć, który kierunek zawodzi i która warstwa za niego odpowiada.

Powiązane artykuły