VPN na routerze działa, ale klienci LAN nie mają internetu

Router dociera do internetu przez swój tunel, a urządzenia za nim nie. Przekazywanie, translacja i trasy powrotne to odrębne uprawnienia.

Status mówi, że tunel jest aktywny, przeglądarka na samym routerze wczytuje strony, a każde urządzenie za nim nadal kończy się przekroczeniem czasu. Ta kombinacja zawęża problem do warstwy, której większość poradników VPN nigdy nie wspomina: router nie jest jedynym hostem, którego pakiety muszą przetrwać tunel. Ruch generowany lokalnie i ruch przekazywany idą różnymi ścieżkami przez to samo pudełko. Przetestuj z klienta, a różnica przestaje być teoretyczna.

Odczytaj awarię z hosta LAN

Zacznij od urządzenia, które zawodzi, bo diagnostyka uruchomiona na routerze odpowiada na inne pytanie. Potwierdź, że domyślna brama klienta to ten router, zanotuj jego adres źródłowy i podsieć, a następnie sprawdź, co wychodzi z interfejsu tunelu routera.

Jeśli adres klienta jest translowany, strona zdalna widzi adres tunelu i stamtąd wszystko wygląda zdrowo, podczas gdy klient nadal zawodzi. Jeśli nie jest translowany, strona zdalna musi znać trasę powrotną do podsieci klienta, a wiele bram nie ma takiej trasy domyślnie. Tak czy inaczej sukces samego routera jest nieistotny, bo jego pakiety powstały lokalnie i nigdy nie przeszły ścieżki przekazywania.

Ruch lokalny i przekazywany to dwie różne rzeczy

Linux i większość firmware'u routerów traktują pakiety powstałe w pudełku inaczej niż pakiety przez nie przechodzące. Łańcuch output widzi pierwszy rodzaj, łańcuch forward widzi drugi, a polityka dopasowana do ruchu samego routera może pozostawić przekazywanie nietknięte.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Sprawdź, czy przekazywanie jest w ogóle włączone, a potem czytaj łańcuch forward, a nie łańcuch output. Reguła zezwalająca na szyfrowane połączenie zewnętrzne nie jest regułą zezwalającą na przekazywanie odszyfrowanych pakietów, a pomieszanie tych dwóch daje dokładnie ten objaw. Aktywny tunel dowodzi tylko pierwszego.

Trasa powrotna też musi istnieć

Translacja źródła decyduje, czy trasa powrotna jest potrzebna. Przy maskowaniu na interfejsie tunelu odpowiedzi wracają na adres tunelu, a router je odtłumacza. Bez tego zdalna brama potrzebuje jawnej trasy do podsieci klienta, a jej własna polityka musi dopuszczać ten kierunek.

Zanotuj, który z dwóch wariantów stosuje wdrożenie, zanim cokolwiek zmienisz, bo naprawy prowadzą w przeciwnych kierunkach. Dodanie translacji ukrywa brakującą trasę powrotną i psuje aplikacje wymagające oryginalnego adresu źródłowego. Dodanie trasy powrotnej bez translacji zawodzi po cichu, gdy zdalny firewall odrzuca nieznane źródło. Wybierz jeden, udokumentuj i dopasuj drugą stronę.

DNS klienta należy do tej samej analizy. Resolver routera może odpowiadać, podczas gdy klient wskazujący inny serwer nie dostaje niczego.

Zweryfikuj jeden przepływ dozwolony i jeden zabroniony

Po korekcie przetestuj nowe połączenie z klienta, a nie istniejącą sesję routera. Następnie potwierdź, że segment, który nie powinien używać tunelu, nadal go nie używa.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Sprawdź zaobserwowany adres źródłowy na drugim końcu, bo to mówi, który wariant naprawdę działa. Zweryfikuj zarówno wyszukiwanie nazw, jak i adres, bo zachowanie resolvera to osobna ścieżka przez to samo pudełko.

Trzymaj reguły ograniczone do sieci klienckich, które potrzebują tunelu, i nie ulegaj pokusie wyłączenia filtra przekazywania, żeby jeden test przeszedł. Ta zmiana naprawia test i usuwa granicę, którą tunel miał zapewniać. Zapisz adres źródłowy, decyzję o translacji i trasę powrotną w jednej notatce, z datą.

Powiązane artykuły