VPN blokuje lokalny LAN w Windows: trasa czy polityka klienta?

Drukarka, NAS albo maszyna deweloperska na własnym biurku przestają odpowiadać w chwili, gdy łączy się służbowy VPN. Czasem jedna komenda trasy naprawia to w sekundach; czasem ta sama trasa jest poprawna, a pakiety nadal znikają, co oznacza, że patrzysz na inny problem o podobnym objawie. Decyzja sprowadza się do trzech pytań, a zadawanie ich w złej kolejności jest powodem, dla którego ludzie spędzają cały wieczór na usuwaniu i ponownym dodawaniu tras.

Trzy pytania przed każdą komendą

Po pierwsze: czy istnieje wpis dla lokalnego prefiksu i czy wskazuje na fizyczny adapter? Po drugie: czy klient otrzymuje przy łączeniu zgodę albo odmowę dla sieci lokalnej od bramy? Po trzecie: czy potrzebujesz tylko dostępu wychodzącego do LAN, czy coś w internecie też musi dotrzeć do usługi działającej na twojej maszynie?

Pierwsze pytanie oddziela usterkę routingu od usterki filtrowania. Drugie mówi, czy poprawka trasy w ogóle może działać. Trzecie zmienia naprawę: trasa naprawia ruch wychodzący, natomiast nieosiągalna usługa przychodząca to zwykle problem dowiązania nasłuchu i drogi powrotnej, który trasa jeszcze pogarsza.

Pytanie pierwsze: trasa, filtr czy nazwa

Przeczytaj tabelę, zanim coś do niej dodasz. Indeks interfejsu ma znaczenie, bo każda komenda trasy poniżej jest do niego zakotwiczona:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Podsieć podłączona bezpośrednio zwykle zachowuje trasę on-link nawet przy aktywnym tunelu, więc wpis może istnieć, a ruch nadal może zawodzić. Ta kombinacja jest sygnaturą filtra działającego po routingu i to jest przypadek, w którym druga, bardziej szczegółowa trasa nie zmienia absolutnie nic.

Testuj osobno po adresie i po nazwie. Jeśli ping 192.168.1.50 odpowiada, a net view 192.168.1.50 nie, tabela routingu nigdy nie była problemem: tunel zmienił resolver, a lokalna nazwa nie jest już rozwiązywana. Dodawanie do tego trasy to zmarnowana praca.

Pytanie drugie: czy brama zezwala na dostęp do lokalnego LAN?

Komercyjny klient instaluje więcej niż trasy. Otrzymuje przy łączeniu politykę, a ta polityka może zawierać wyraźne zezwolenie na sieć lokalną. We wdrożeniach Cisco IPsec polityka grupowa niesie ustawienie split-tunneling i osobną flagę dostępu do lokalnego LAN; pole wyboru w kliencie jest prośbą, której brama może odmówić. W AnyConnect profil kontroluje listy włączania i wykluczania splitu oraz to samo zezwolenie. W Windows RRAS odpowiednikami są opcja domyślnej bramy w profilu oraz trasy statyczne przydzielane przez serwer.

Gdy flaga jest wyłączona, udokumentowane zachowanie polega na tym, że klient blokuje ruch do bezpośrednio podłączonej podsieci, mimo że istnieje poprawna, bardziej szczegółowa trasa. Dlatego też trasy, których klient nie posiada, mogą znikać sekundy po dodaniu: klient odbudowuje stan, który kazano mu zbudować, a nie walczy z tobą.

Dziennik klienta zapisuje decyzję przy łączeniu, a jego przeczytanie jest szybsze niż jakikolwiek eksperyment na maszynie. Jeśli dziennik mówi, że dostęp lokalny jest zablokowany, zatrzymaj się: żadna poprawka z wiersza poleceń tego nie przetrwa, a pozostają tylko zmiana polityki, dotarcie do zasobu przez tunel albo zamknięcie klienta w maszynie wirtualnej i pozostawienie hosta w sieci lokalnej.

Pytanie trzecie: którego kierunku potrzebujesz?

Ruch wychodzący do pobliskiego urządzenia to pytanie o routing. Skieruj prefiks LAN na lokalną bramę z metryką wystarczająco niską, by pokonać domyślną trasę tunelu:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Druga forma przypina jedno urządzenie, czego chcesz, gdy jeden adres to całe wymaganie. Odpowiednik netsh zapisuje tę samą decyzję po nazwie interfejsu, a nie po indeksie:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Komendy trasy kończą się błędem Parametr jest niepoprawny, gdy adres i maska nie pasują do siebie, na przykład adres hosta z maską /24. Dla trasy podsieci użyj adresu sieci, a dla pojedynczego hosta maski hosta.

Ruch przychodzący jest inny. Serwer VNC albo SSH na tej samej maszynie staje się nieosiągalny, gdy odpowiedzi na połączenie przychodzące wychodzą przez bramę VPN i nigdy nie wracają. Sprawdź, na czym usługa nasłuchuje, zanim dotkniesz tras:

netstat -ano | findstr :5900

Nasłuch związany z jednym konkretnym adresem nie odpowie na drugim interfejsie. Dowiązanie go do wszystkich interfejsów to świadoma decyzja, podjęta razem z regułą zapory ograniczoną do sieci, której ufasz. Dopiero potem naprawa trasy przywraca drogę powrotną.

Zastosuj najmniejszą pasującą zmianę

Innym częstym ruchem jest odznaczenie „Używaj domyślnej bramy w sieci zdalnej” w zaawansowanych właściwościach IPv4. To utrzymuje ruch internetowy lokalnie, ale robi dwie rzeczy naraz: VPN przestaje być ścieżką domyślną, a klient przestaje otrzymywać trasy do sieci zdalnej, w tym multicast. Odznacz to, a zdalny LAN zniknie, chyba że serwer wypycha konkretne zdalne prefiksy potrzebne każdemu klientowi.

Ta asymetria decyduje o kolejności pracy. Jeśli zdalna strona ma pozostać w pełni osiągalna, wypychaj zdalne podsieci z serwera i zostaw lokalną domyślną w spokoju. Jeśli nie możesz zmienić serwera, dodaj trwałą trasę do zdalnego prefiksu przez adres przydzielony przez tunel i sprawdź za pomocą route print, czy prefiks wskazuje interfejs VPN, podczas gdy domyślna nadal wskazuje fizyczną bramę.

Następnie potwierdź, że naprawa przetrwa ponowne połączenie, bo trasy nietrwałe giną wraz z adapterem, a skrypt uruchamiany po każdym połączeniu jest dla nich uczciwym miejscem. Przetestuj jedno urządzenie lokalne i jeden zasób zdalny w tej samej sesji, rozłącz, połącz ponownie i przetestuj jeszcze raz. Jeśli urządzenie lokalne nadal zawodzi, a trasa wygląda poprawnie, wróć do pytania drugiego: klient filtruje, a odpowiedzią jest zmiana polityki, a nie druga konkurencyjna trasa.