Sieć lokalna nieosiągalna przy połączonym VPN? Cztery kontrole

Tunel się podnosi, intranet się pojawia, a drukarka przestaje odpowiadać. W sieci LAN nic się nie zepsuło; klient zmienił ścieżkę, której używa dla adresów, których nie traktuje już jako lokalne. Przejdź cztery kontrole poniżej po kolei i zatrzymaj się, gdy jedna pokaże konkretną niezgodność, bo ten sam objaw ma cztery częste przyczyny i tylko jedna z nich znika po zmianie ustawień VPN.

Najpierw spójrz na tablicę tras, którą zainstalował klient

Otwórz tablicę tras klienta, gdy VPN jest połączony. W systemie Linux użyj ip route, w Windows route print lub Get-NetRoute, a w macOS netstat -rn. Szukasz trasy domyślnej przez tunel i tego, co stało się z fizyczną trasą domyślną.

Klient z pełnym tunelem często dodaje dwie trasy półdomyślne, 0.0.0.0/1 i 128.0.0.0/1, zamiast zastąpić 0.0.0.0/0. Pierwotna trasa domyślna pozostaje widoczna, ale przegrywa każde wyszukiwanie, dlatego tablica może wyglądać na nietkniętą, podczas gdy cały ruch poza podsiecią się przesuwa. Jeśli klient VPN oferuje opcję tunelu dzielonego i polityka na to pozwala, to najczystsza naprawa.

Jeśli tunel musi pozostać domyślny, przypnij zamiast tego lokalną podsieć. W systemie Linux trasa wskazuje interfejs fizyczny i bramę; w Windows dodaj -p, aby była trwała, i odczytaj numer interfejsu z route print, zamiast go zgadywać:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Przypięta trasa trzyma się tylko tak długo, jak długo wskazany adres się nie zmienia. Laptop, który przy każdym połączeniu dostaje nowy numer karty Wi-Fi, znów złamie regułę, więc sprawdź adres interfejsu, zanim uznasz, że naprawa się nie udała.

Po drugie, potwierdź, że adres w ogóle był lokalny

Jeśli cel leży w połączonej podsieci, trasa domyślna tunelu nigdy nie obowiązuje i VPN nie jest przyczyną. Drukarka pod 192.168.1.40 na kliencie z 192.168.1.0/24 używa trasy połączonej; jeśli ten adres zawodzi, patrz na urządzenie, przełącznik lub zaporę na kliencie, a nie na VPN.

Przypadek, który myli ludzi, to publiczny adres lokalnego serwera. Z wnętrza LAN dotarcie do adresu WAN routera i powrót wymaga hairpin NAT, a wiele routerów po prostu tego nie implementuje dla przekierowania portów. Przetestuj adres prywatny obok publicznego. Jeśli prywatny działa, a publiczny nie, VPN tylko ujawnił ograniczenie NAT, które istniało już wcześniej.

Nazwa hosta pogarsza sprawę. Jeśli lokalna nazwa rozwiązuje się teraz na publiczny adres, klient będzie dalej próbował ścieżki, która nie może wrócić. Do testu użyj adresu prywatnego, a potem napraw nazwę, zamiast dodawać kolejne przekierowanie portu.

Po trzecie, sprawdź, kto teraz odpowiada na nazwy

Firmowy resolver zna intranet i zwykle nic nie wie o nazwie hosta NAS, nazwie Bonjour drukarki ani lokalnym aliasie routera. Gdy VPN przepycha swoje serwery DNS, te nazwy przestają się rozwiązywać, choć ich adresy są nadal osiągalne. Odpytaj nazwę bezpośrednio i porównaj odpowiedź z adresem, o którym wiesz, że urządzenie go ma.

W systemie Linux resolvectl query nas.local pokazuje, który resolver odpowiedział. W Windows nslookup nas.local wskazuje serwer, a ipconfig /all pokazuje kolejność resolverów. Jeśli lokalnym sufiksem zajmuje się teraz firmowy resolver, przekieruj ten sufiks z powrotem do lokalnego resolvera albo użyj adresu IP dla urządzenia.

Wykrywanie to osobna warstwa. mDNS i rozgłaszanie nie przechodzą przez trasowany tunel, więc urządzenie może być osiągalne po adresie, a jego nazwa pozostaje niewidoczna. Reflektor albo lokalny wpis DNS to rozwiązują; trasa nie.

Po czwarte, sprawdź, czy druga maszyna też jest w VPN

Gdy maszyna, do której chcesz dotrzeć, również uruchamia klienta VPN, twoja sesja może dotrzeć, a odpowiedź wyjść drugim tunelem. Powstaje połączenie, które się zestawia i potem zastyga, albo próba RDP i SSH, która po twojej stronie kończy się przekroczeniem czasu bez błędu. Sprawdź tablicę tras drugiego hosta i jego ścieżkę domyślną, zanim obwinisz swój klient.

Sprawdź też adres, na którym nasłuchuje usługa. Nasłuch przypięty tylko do adresu tunelu przyjmuje połączenia z VPN i odrzuca je z LAN, nawet gdy routing jest idealny. To konfiguracja usługi, nie ścieżka sieciowa, i jest częsta na interfejsach zarządzania zamkniętych na adres VPN.

Utrzymuj ścieżkę zarządzania, która nie zależy od tunelu: statyczna trasa wskazująca twoją sieć źródłową, inny interfejs podłączony do LAN albo konsola całkowicie omijająca tunel. Zaprojektowanie tej ścieżki po utracie sesji jest znacznie trudniejsze niż dodanie jej przed następnym połączeniem.

Zastosuj naprawę, która pasuje do nieudanej kontroli

Jeśli tablica tras pokazała przejęcie półdomyślne, wybierz tunel dzielony, gdy polityka pozwala, a przypiętą trasę lokalną, gdy nie. Jeśli adres okazał się publiczny, przełącz test i nazwę na adres prywatny. Jeśli resolver zmienił właściciela, ogranicz się do lokalnego sufiksu albo użyj adresu. Jeśli drugi host jest w tunelu, napraw jego ścieżkę powrotną lub przypięcie nasłuchu.

Zmień jedną rzecz, a potem powtórz tę samą kontrolę. Trasa dodana dla złej podsieci, sufiks resolvera z literówką i przypięta trasa na interfejsie, który dostaje nowe numery, wyglądają jak pierwotna awaria. Powtórzenie jest tym, co oddziela naprawę od przypadku.

Zapisz trasę, adres i resolver, które działały, gdy VPN był połączony. Następne połączenie zmieni co najmniej jedno z nich, a notatka zamieni następną awarię w krótkie porównanie zamiast nowego dochodzenia.