Jak sprawdzić, co VPN w Windows naprawdę trasuje w PowerShellu
Podłączony kafelek VPN nie dowodzi pokrycia. Przeczytaj zapisaną flagę profilu, aktywną tabelę tras i reguły NRPT w tej kolejności.
Podłączyłem klienta VPN na laptopie z Windows 11, kafelek przeszedł w stan Connected, otworzył się wewnętrzny udział plików, a publiczna witryna nadal ładowała się bezpośrednio z Wi-Fi biura. Ta mieszanka wygląda jak zepsuty tunel. To normalne wyjście profilu, który część ruchu wysyła przez VPN, a resztę zostawia na karcie fizycznej. Wymuszone tunelowanie zmienia to, której trasie domyślnej Windows daje pierwszeństwo; nie usuwa bardziej szczegółowych tras i nie obiecuje, że ruch zatrzyma się po zerwaniu połączenia. Poniżej przedstawiam kolejność, którą przechodzę, gdy klient twierdzi, że ma pokrycie: stan klienta, zapisany profil, zastosowane trasy, resolver, a potem rzeczywiste przepływy.
Zacznij od klienta, a potem przestań mu ufać
Klient jest właściwym miejscem na start tylko dlatego, że mówi, który profil jest aktywny. Otwórz właściwości połączenia i zanotuj dokładną nazwę profilu, czy utworzono go dla bieżącego użytkownika, czy dla wszystkich na maszynie, i która karta pojawia się w ncpa.cpl po połączeniu. Na moim testowym laptopie karta nosiła nazwę profilu, co ułatwiało czytanie wyjścia tras. Na innych maszynach pojawia się jako wpis WAN Miniport, a nazwa nic ci nie mówi.
Tego, czego klient nie może ci powiedzieć, to pokrycie. Podłączony kafelek opisuje stan tunelu, a nie spis celów. Klienci firm trzecich również trzymają własną konfigurację, więc natywny profil Windows i każda właściwość, którą z niego odczytasz, mogą nie mieć nic wspólnego z tym, co zainstalował ten klient. Jeśli VPN przyszedł przez AnyConnect, OpenVPN GUI, WireGuard lub agenta dostawcy, poniższe kontrole PowerShell w większości nie mają zastosowania i zamiast tego powinieneś przeczytać własne ustawienia split-tunnelu i routingu tego klienta.
Czytaj zapisany profil, nie kafelek
Dla natywnego profilu Windows (IKEv2, L2TP, SSTP lub profilu wypychanego przez MDM) zapisana decyzja o split-tunnelu to jedna właściwość:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixDodaj -AllUserConnection, gdy profil utworzono dla wszystkich na urządzeniu. Bez tego czytasz listę bieżącego użytkownika, która może być pusta lub zawierać inny wpis o podobnej nazwie. Wartość False w SplitTunneling oznacza, że profil zapisano jako pełny tunel: Windows instaluje trasę domyślną przez kartę VPN. True oznacza split tunnel, a pokrycie zależy wtedy wyłącznie od tras i reguł rozwiązywania nazw, które wypycha ten profil.
Traktuj tę wartość jako konfigurację, nie jako obserwację. Zapisuje, o co profil prosił w momencie połączenia. Windows może skończyć z innymi zastosowanymi trasami z powodu bardziej szczegółowej trasy innego interfejsu, ustawienia zasad lub resztki z poprzedniego połączenia, więc wartość logiczna nigdy nie rozstrzyga sprawy sama.
Porównaj zapisaną wartość z zastosowaną tabelą tras
Po połączeniu wylistuj trasy na karcie tunelu zamiast przewijać całą tabelę:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute to użyteczna połowa. Odpowiada na pytanie, na które klient nigdy nie odpowiada: dla tego celu, którego interfejsu i którego adresu źródłowego Windows naprawdę użyje? Uruchom go dla hosta wewnętrznego, hosta publicznego i wszystkiego, co uważasz za celowy wyjątek. Profil pełnego tunelu powinien pokazać interfejs tunelu dla adresu publicznego. Profil split tunnel zwykle pokazuje tam kartę fizyczną, podczas gdy prefiksy wewnętrzne nadal rozwiązują się przez VPN.
Dwie pułapki wyjaśniają większość zgłoszeń „trasuje w złą stronę”. Najbardziej szczegółowy prefiks zawsze wygrywa, więc /24 na karcie fizycznej bije trasę domyślną na VPN, niezależnie od tego, jak niska jest metryka tunelu. Metryka rozstrzyga tylko remisy między trasami dla tego samego prefiksu. A IPv4 i IPv6 są rozstrzygane osobno: profil obejmujący 0.0.0.0/0 może zostawić IPv6 na łączu lokalnym, przez co witryna dual-stack wygląda na wpół tunelowaną. Sprawdź Get-NetRoute -AddressFamily IPv6, zanim uznasz, że tunel jest w porządku.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Sprawdź rozwiązywanie nazw osobno za pomocą NRPT
Wewnętrzne nazwy, które zawodzą, gdy wewnętrzne adresy IP działają, wskazują na zasady resolvera, a nie na routing. Windows rozstrzyga DNS dla każdej przestrzeni nazw przez tabelę zasad rozwiązywania nazw, niezależną od tabeli tras:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexGdy reguła pasuje do *.corp.example, zapytania dla tej przestrzeni nazw idą do serwerów DNS tunelu, nawet jeśli ścieżka danych do tych serwerów w trybie split tunnel pozostaje na karcie fizycznej. Taki jest projekt i dlatego test przeglądarki otwierający publiczną witrynę nic nie mówi o nazwach wewnętrznych. Jeśli karta wymienia oczekiwane serwery, ale wyszukiwania nadal idą gdzie indziej, porównaj kolejność reguł NRPT i sprawdź, czy jako pierwsza pasuje bardziej szczegółowa przestrzeń nazw.
Zweryfikuj przepływy, a potem zdecyduj, o co naprawdę prosiłeś
Przejdź cele w ustalonej kolejności, aby wyniki były porównywalne między maszynami: adres publiczny, adres wewnętrzny, nazwa wewnętrzna i jeden celowy wyjątek, na przykład lokalna drukarka lub rozmowa wideo. Zanotuj interfejs i adres źródłowy, które Find-NetRoute zwraca dla każdego. Po każdej zmianie zasad połącz się ponownie i powtórz te same cztery kontrole; tabela tras po ponownym połączeniu jest jedynym dowodem, że nowy profil wszedł w życie.
Następnie oddziel routing od egzekwowania. Wymuszone tunelowanie preferuje tunel dla objętego ruchu, dopóki jest podniesiony. To nie jest kill switch. Jeśli wymaganiem jest, aby nic nie opuszczało maszyny, gdy tunel padnie, musi to pochodzić z projektu blokującego: profil zapory powiązany ze stanem tunelu, profil zawsze włączony z filtrami ruchu lub własna opcja zamknięcia przy awarii klienta dostawcy. Wymuszone tunelowanie musi też pozostawić adres samego serwera VPN osiągalny poza tunelem, a blokowanie go w imię „wymuszania wszystkiego” to pewny sposób, by odciąć się od połączenia, które próbujesz wyegzekwować.
Zanim cokolwiek zmienisz, przejdź tę listę. Każdy nieudany punkt zawęża, gdzie leży prawdziwy problem.
- Nazwa i zakres profilu potwierdzone, z
-AllUserConnectiondla profili na poziomie maszyny. SplitTunnelingprzeczytany i potraktowany jako konfiguracja, nie jako dowód pokrycia.- Trasy karty tunelu wylistowane osobno dla IPv4 i IPv6.
Find-NetRouteuruchomiony dla jednego celu publicznego, jednego wewnętrznego i jednego wyjątku.- Reguły NRPT sprawdzone, zanim trasy obwiniono o błąd nazwy.
- Wymóg blokowania przeczytany ponownie: preferowany routing to nie to samo co wymuszone blokowanie.
Decyzja o pełnym lub dzielonym tunelu należy do właściciela profilu, a notatki Microsoftu dotyczące routingu opisują zachowanie, które Windows realizuje, gdy profil je ustawia. Microsoft: tunelowanie wymuszone i dzielone to źródło, które trzymam otwarte podczas czytania wyjścia.