Tunel dzielony w Windows: pole bramy i brakujący prefiks

Windows wysyła wszystko przez tunel, dopóki nie odznaczysz jednego pola, a potem za mało, dopóki nie dodasz podsieci. Oba należą do tej samej zmiany.

Tunel zgłasza połączenie, a wiki nadal się ładuje. Potem pobieranie się zatrzymuje, a udział na półce przestaje odpowiadać. Tunel zrobił swoje, a profil po prostu rościł sobie prawo do każdego celu.

Windows traktuje połączenie VPN jako decyzję o trasie. Dopóki ta decyzja nie zostanie zawężona, maszyna zachowuje się, jakby przeprowadziła się do biura.

Dlaczego działający tunel wygląda jak awaria

Profil, któremu wolno używać zdalnej bramy, instaluje trasę domyślną przez tunel. Wtedy każdy cel spoza łącza lokalnego wychodzi przez zaporę biura. Lokalne udziały przestają odpowiadać, bo ich ruch podróżuje teraz na inny kontynent i wraca. Nic w stanie klienta tego nie odzwierciedla.

Objawy mylą celowo. Rozwiązywanie nazw może nadal działać, gdy udział kończy się przekroczeniem czasu, albo odwrotnie. Użytkownik zgłasza, że VPN jest zepsuty, klient zgłasza, że u niego jest dobrze, i oba stwierdzenia są trafne.

Pole wyboru ukryte w oknie IPv4

Ustawienie jest kilka okien głębiej. Otwórz ncpa.cpl, kliknij prawym przyciskiem połączenie, potem właściwości IPv4, potem Zaawansowane, i wyczyść opcję, która pozwala połączeniu stać się zdalną bramą domyślną. To jedno pole decyduje, czy profil jest pełnym tunelem. Wszystko inne w profilu nadal obowiązuje.

Porównaj route print -4 przed ponownym połączeniem i po nim. Wpis 0.0.0.0, który wcześniej wskazywał tunel, powinien zniknąć, a prefiksy firmowe powinny nadal być na miejscu.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Zmiana metryki interfejsu nie jest zamiennikiem. Metryka rozstrzyga tylko między dwiema konkurującymi trasami domyślnymi, a klient, który przy każdym połączeniu instaluje na nowo własną trasę domyślną, wygrywa ten wyścig niezależnie od ustawionej liczby.

Prefiks, którego nikt nie wymienił

Tunel dzielony udostępnia dokładnie te prefiksy, które zapisano w profilu. Podsieć biurowa dodana po napisaniu profilu pozostaje nieosiągalna, choć tunel jest całkowicie zdrowy. Raport przychodzi wtedy jako jeden zepsuty serwer, a nie zepsuty VPN.

Trasa dodana ręcznie zasłania lukę, dopóki adres bramy się nie zmieni. Zapisanie prefiksu w połączeniu jest trwalsze, bo prefiks podąża wtedy za połączeniem, a nie za zgadywanym adresem.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Czytaj zapisaną listę i żywą tabelę razem. Zapisany prefiks może istnieć, a tabela nigdy go nie otrzyma, co zdarza się, gdy agent zarządzania filtruje trasy po podniesieniu połączenia. Dzieje się też odwrotnie, gdy trasa w rejestrze wskazuje na wyłączony adapter. Żaden z tych widoków osobno nie opowiada całej historii.

Udowodnienie wyniku po restarcie

Śledź w obu kierunkach i rozwiązuj po nazwie. Ślad publiczny powinien wychodzić przez dostawcę, ślad wewnętrzny powinien wchodzić w tunel, a host wewnętrzny powinien odpowiadać po nazwie, a nie tylko po adresie.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Powtórz po rozłączeniu, ponownym połączeniu i jednym restarcie. Prefiks, który przetrwa ręczne ponowne połączenie i znika po restarcie, nigdy nie został zapisany w profilu.

Zostaw w teście także drukarkę i NAS, bo tunel dzielony, który odcina urządzenia obok laptopa, rozwiązał jeden problem, tworząc mniejszy i bardziej irytujący. Dokumentacja Microsoftu dla Add-VpnConnectionRoute to miejsce, w którym sprawdzasz pisownię parametrów względem wersji swojego modułu.

Powiązane artykuły