Dlaczego Twoja VPN w Windows zabija lokalną drukarkę i jak temu zapobiec

Połącz VPN i drukarka znika, udział NAS przestaje się otwierać, a sesja Pulpitu zdalnego do komputera obok kończy się przekroczeniem czasu. Nic się nie zepsuło. Klient dodał trasę domyślną i teraz posiada każde miejsce docelowe, które laptop potrafi nazwać, łącznie z tymi trzy metry dalej. To cały mechanizm, a nazywanie tego awarią VPN jest właśnie tym, co zamienia poprawkę w jednej linii w zgłoszenie do pomocy technicznej.

Najpierw przeczytaj tabelę tras

Zanim cokolwiek zmienisz, przechwyć tabelę IPv4 za pomocą route print -4 i zachowaj wynik. Połącz się, przechwyć ponownie i porównaj wiersze 0.0.0.0: aktywna trasa domyślna wskazuje interfejs, a jeśli tym interfejsem jest tunel, lokalne drukowanie i przeglądanie są najpierw wysyłane do biura.

Numer interfejsu w drugiej kolumnie to ten, na który trasa trwała będzie musiała się później powołać, więc zapisz go, gdy tunel jest aktywny. To także wartość, która zmienia się przy odtworzeniu adaptera, dlatego trasy przypięte do niej mogą po cichu przeżyć swoją użyteczność.

Usuń trasę domyślną, na trzy sposoby

W profilu wbudowanym w Windows kontrolką jest pole wyboru. Otwórz właściwości połączenia, IPv4, potem Zaawansowane, i wyczyść Use default gateway on remote network; nowsza aplikacja Ustawienia ukrywa ten sam dialog o warstwę głębiej. Z podniesionego wiersza poleceń ta sama zmiana to jeden cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

OpenVPN profil działa inaczej, dlatego jego zachowanie myli tych, którzy oczekują pola wyboru. Jego dyrektywa redirect-gateway def1 wcale nie zastępuje trasy domyślnej; instaluje dwie trasy półzakresowe, 0.0.0.0/1 i 128.0.0.0/1, które razem wygrywają z domyślną, nie usuwając jej. Ponieważ pierwotna domyślna przeżywa, dodanie prefiksu wskazującego na net_gateway odsyła do lokalnego routera tylko ten prefiks. Ten szczegół wyjaśnia, dlaczego poprawką dla profilu def1 jest trasa prefiksu, a nie pole wyboru, którego nikt nie potrafi znaleźć.

Dodaj z powrotem tylko to, co należy do pracy

Bez trasy domyślnej tunel nic nie przenosi, więc prefiksy robocze trzeba nazwać wprost. Cmdlet, który wiąże prefiks z połączeniem, jest bezpieczniejszy niż trasa trwała, ponieważ instaluje się tylko na czas aktywności tego połączenia i nie zależy od numeru interfejsu:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

Starsze podejście nadal działa i nadal jest w każdej liście kontrolnej: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, z własnym indeksem interfejsu i adresem bramy tunelu. Przetrwa restarty, co jest celem i zarazem zagrożeniem, bo przy następnym rozruchu indeks może należeć do czegoś innego.

Resztę rozstrzygają metryki. Jeśli zarówno adapter fizyczny, jak i tunelowy żądają trasy dla tego samego prefiksu, wygrywa niższa metryka, a podnoszenie metryki tunelu jest legalną kontrolą po stronie klienta, a nie hackiem.

Gdy serwer decyduje za Ciebie

Klient, który ignoruje Twoje pole wyboru, zwykle jest posłuszny polityce. Profile Cisco noszą ustawienie Allow Local LAN Access, a headend może wypchnąć politykę tunnel-all, która unieważnia to, co klient wolałby; we wdrożeniu tunelu obowiązkowego nie ma lokalnego przełącznika do przestawienia. Czytaj dziennik klienta pod kątem wypchniętych tras i linii polityki, zamiast sprawdzać ponownie ten sam dialog.

Potem spójrz na rozwiązywanie nazw, które jest osobnym przełącznikiem od routingu. Tunel dzielony nadal może otrzymać wewnętrzny resolver i sufiks wyszukiwania, więc urządzenie lokalne jest osiągalne po adresie i nieodnajdywalne po nazwie, dopóki strona DNS też nie zostanie naprawiona.

Nakładanie się to inny problem

Jeśli LAN w domu i LAN w biurze dzielą prefiks taki jak 192.168.0.0/24, żadna trasa nie potrafi ich rozróżnić. Każdy pakiet w tym zakresie ma jeden wynik wyszukiwania, a poprawką jest przenumerowanie jednej strony albo dotarcie do biura przez przetłumaczony adres z puli. Dodawanie bardziej szczegółowych tras tylko przesuwa to, która połowa sieci się psuje.

Zakończ jednym sprawdzeniem zamiast pięciu: połącz się, a następnie uruchom tracert wobec hosta wewnętrznego i publicznego. Pierwszy przeskok powinien się różnić, a jeśli się nie różni, podział nie działa, cokolwiek raportuje klient. Potem połącz się jeszcze raz i powtórz, bo wypchnięte trasy wracają z każdą sesją.