Przekonanie, że sam tryb klienta zabija dostęp do LAN, prowadzi ludzi do niewłaściwego menu ustawień, a prawdziwe przyczyny są zwykle dwie. Tunel nie usuwa mostu LAN i nie blokuje komunikacji między klientami przewodowymi i bezprzewodowymi. Dostęp lokalny psuje funkcja inspekcji w ścieżce przekazywania routera albo zakres adresów LAN, który przesunął się, gdy firmware to zrobił. Oba dają tę samą skargę i żadnego nie naprawia ponowna instalacja profilu VPN.

Mit i co naprawdę zmienia tryb klienta

Tryb klienta dodaje interfejs tunelu i domyślną trasę, która przez niego prowadzi, a następnie przekazuje ruch LAN do tego tunelu. Most między portami przewodowymi a radiami bezprzewodowymi pozostaje nietknięty, podobnie jak lokalne przełączanie. Zmienia się polityka: jaki ruch jest przekazywany, gdzie jest tłumaczony i jaki resolver otrzymują klienci.

Ta różnica ma znaczenie, ponieważ zepsuty LAN zwykle oznacza, że zmieniła się jedna z tych trzech polityk, a nie że router przestał być przełącznikiem. Router, który nadal odpowiada na własną stronę administracyjną, jest dowodem, że interfejs LAN żyje. Router, który nie odpowiada na nic, ma inny problem, na przykład zmieniony adres LAN albo klienta w niewłaściwej podsieci.

Więc użytecznym pierwszym krokiem jest ustalenie, która warstwa się zepsuła, a nie zmiana warstwy, którą podejrzewasz.

Przetestuj trzy cele, zanim dotkniesz ustawienia

Z klienta przewodowego przetestuj trzy cele osobno i zapisz każdy wynik: własny adres LAN routera, inne urządzenie w tym samym przełączniku po IP i coś osiągalnego tylko przez tunel. Zrób to w tej kolejności, ponieważ każdy wynik wyklucza inną warstwę. W pierwszej rundzie używaj adresów, a nie nazw, ponieważ błąd nazwy miesza DNS z pytaniem o łączność.

Wzorzec odpowiedzi jest diagnozą. Router, który odpowiada, gdy urządzenia lokalne nie, wskazuje na lokalne przełączanie lub funkcję filtrowania, a nie na routing. Urządzenia lokalne, które odpowiadają, gdy strona tunelu nie, wskazują na trasę tunelu lub zaporę zdalną. Jeśli wszystko odpowiada po adresie, a nazwy zawodzą, to pytanie o resolver i żadna edycja tras tego nie naprawi.

What answersWhat it points at
Router onlyLAN-side filtering or a broken bridge
Router and local hosts, not remoteTunnel route, NAT or remote firewall
Addresses yes, names noDNS handed to clients by the router
Nothing at allClient subnet or router LAN address changed

Trzymaj tabelę obok wyników testów. Zamienia niejasną skargę w jedną linię, na której można działać.

Warstwa bezpieczeństwa w ścieżce przekazywania

Routery konsumenckie coraz częściej mają funkcję inspekcji, która obserwuje przekazywany ruch, i działa ona w tej samej ścieżce, która przenosi pakiety z LAN do tunelu. Gdy ta inspekcja nie potrafi sklasyfikować ruchu tunelu, przekazywanie może się zatrzymać, podczas gdy sam tunel pozostaje aktywny, a router zgłasza zdrowe połączenie. Nic w dzienniku VPN tego nie pokazuje, ponieważ VPN faktycznie się połączył.

Diagnoza to kontrolowany eksperyment, a nie trwała zmiana. Zapisz bieżące ustawienie, wyłącz funkcję na czas jednego testu, podnieś tunel ponownie i przetestuj jeden lokalny host po adresie. Przekazywanie, które wraca, jest dowodem, którego potrzebowałeś, a kompromis staje się wtedy decyzją, a nie domysłem. Jeśli nic się nie zmieni, włącz ją natychmiast ponownie i przejdź do przyczyny adresacji.

Pozostawienie płatnej funkcji bezpieczeństwa wyłączonej, aby tunel dalej działał, to kompromis, który trzeba podjąć świadomie i zapisać. Warto też zapytać, czy tunel powinien być na innym urządzeniu, ponieważ router, który musi wszystko sprawdzać, i router, który musi wszystko przekazywać, to dwie różne prace.

Druga przyczyna: zakres LAN się przesunął

Aktualizacje firmware regularnie przywracają adres LAN do wartości domyślnej producenta, a niektóre routery mają wyraźny przełącznik trybu, który decyduje, czy LAN zachowuje zakres prywatny, czy dziedziczy go od urządzenia powyżej. Klient, który oczekuje 192.168.8.x, może trafić na 10.64.0.x, a wtedy sesja SSH do hosta wygasa, chociaż tunel jest całkowicie zdrowy.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Odczytaj prefiks i bramę z dzierżawy, zanim otworzysz stronę routera. Pierwsze dwie komendy pokazują, co klient faktycznie otrzymał, a trzecia pokazuje, którego interfejsu klient użyłby dla adresu lokalnego, i tak ujawnia się pozostała trasa lub przestarzała podsieć. Następnie porównaj to ze stroną LAN i trybem, w którym jest router.

Jeśli zakres nie może wrócić, zaktualizuj każdy obiekt, który go nazywa: rezerwacje DHCP, każdą trasę statyczną do starej podsieci i każdą regułę zapory z poprzednim prefiksem. Zakres kolidujący ze zdalną podsiecią tunelu jest gorszym wariantem, ponieważ urządzenia lokalne pozostają osiągalne, a cele zdalne są po cichu źle kierowane do LAN.

Połącz ponownie i przetestuj ponownie w kolejności pakietów

Po którejkolwiek z dwóch zmian połącz tunel ponownie i powtórz testy w kolejności pakietów: router, host lokalny, host zdalny, potem nazwy, potem aplikacja. Testowanie aplikacji najpierw ukrywa, która warstwa jest jeszcze zepsuta, a ponowna próba przeglądarki z nazwą w pamięci podręcznej może wyglądać jak błąd routingu.

Zapisz wersję firmware, prefiks LAN i stan funkcji inspekcji obok profilu VPN. Wszystkie trzy to konfiguracja, którą następna aktualizacja może nadpisać, a dwie linijki notatek oszczędzają godzinę, którą właśnie spędziłeś.

Powiązane artykuły