Jak zjistit, co VPN ve Windows skutečně směruje v PowerShellu
Připojená dlaždice VPN neprokazuje pokrytí. Přečtěte uložený příznak profilu, živou směrovací tabulku a pravidla NRPT v tomto pořadí.
Připojil jsem klienta VPN na notebooku s Windows 11, dlaždice přešla do stavu Připojeno, otevřela se interní sdílená složka a veřejný web se stále načítal přímo z kancelářské Wi-Fi. Tahle směs vypadá jako rozbitý tunel. Je to normální výstup profilu, který část provozu posílá přes VPN a zbytek nechává na fyzickém adaptéru. Vynucené tunelování mění, kterou výchozí trasu Windows preferuje; nemaže konkrétnější trasy a neslibuje, že provoz po přerušení spojení ustane. Následuje pořadí, podle kterého postupuji, když klient tvrdí pokrytí: stav klienta, uložený profil, aplikované trasy, resolver a pak skutečné toky.
Začněte u klienta a pak mu přestaňte věřit
Klient je správné místo pro začátek jen proto, že vám řekne, který profil je aktivní. Otevřete vlastnosti připojení a poznamenejte si přesný název profilu, zda byl vytvořen pro aktuálního uživatele nebo pro všechny na počítači, a který adaptér se po připojení objeví v ncpa.cpl. Na mém testovacím notebooku adaptér nesl název profilu, což usnadnilo čtení výstupu tras. Na jiných počítačích se objeví jako položka WAN Miniport a název vám nic neřekne.
Co vám klient nemůže říct, je pokrytí. Připojená dlaždice popisuje stav tunelu, ne soupis cílů. Klienti třetích stran si také drží vlastní konfiguraci, takže nativní profil Windows a každá vlastnost, kterou z něj přečtete, nemusí mít nic společného s tím, co ten klient nainstaloval. Pokud VPN přišla přes AnyConnect, OpenVPN GUI, WireGuard nebo agenta dodavatele, níže uvedené kontroly PowerShellu většinou neplatí a měli byste místo nich číst vlastní nastavení rozděleného tunelu a směrování onoho klienta.
Čtěte uložený profil, ne dlaždici
Pro nativní profil Windows (IKEv2, L2TP, SSTP nebo profil protlačený MDM) je uložené rozhodnutí o rozděleném tunelu jediná vlastnost:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixPřidejte -AllUserConnection, když byl profil vytvořen pro všechny na zařízení. Bez něj čtete seznam aktuálního uživatele, který může být prázdný nebo obsahovat jinou položku s podobným názvem. Hodnota False v SplitTunneling znamená, že profil byl uložen jako plný tunel: Windows nainstaluje výchozí trasu přes adaptér VPN. True znamená rozdělený tunel a pokrytí pak zcela závisí na trasách a pravidlech překladu názvů, které profil protlačuje.
Berte tuto hodnotu jako konfiguraci, ne pozorování. Zaznamenává, co profil žádal v okamžiku připojení. Windows může skončit s odlišnými aplikovanými trasami kvůli konkrétnější trase jiného rozhraní, nastavení zásad nebo zbytkové položce z předchozího připojení, takže boolean otázku sám nikdy nerozhodne.
Porovnejte uloženou hodnotu s aplikovanou směrovací tabulkou
Po připojení vypište trasy na adaptéru tunelu místo procházení celé tabulky:
$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 je užitečná polovina. Odpovídá na otázku, kterou klient nikdy nezodpoví: pro tento cíl, které rozhraní a která zdrojová adresa Windows skutečně použije? Spusťte ho pro interní hostitel, veřejný hostitel a cokoli, co považujete za záměrnou výjimku. Profil plného tunelu by měl pro veřejnou adresu ukázat rozhraní tunelu. Profil rozděleného tunelu tam obvykle ukazuje fyzický adaptér, zatímco interní prefixy se stále překládají přes VPN.
Dvě pasti vysvětlují většinu hlášení „směruje to špatně“. Nejspecifičtější prefix vždy vyhrává, takže /24 na fyzickém adaptéru porazí výchozí trasu na VPN, ať je metrika tunelu jakkoli nízká. Metrika jen rozhoduje remízy mezi trasami se stejným prefixem. A IPv4 a IPv6 se rozhodují odděleně: profil, který pokrývá 0.0.0.0/0, může nechat IPv6 na lokálním spoji, což dělá z dual-stack webu napůl tunelovaný web. Ověřte Get-NetRoute -AddressFamily IPv6, než usoudíte, že je tunel v pořá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 |
Ověřte překlad názvů zvlášť pomocí NRPT
Interní názvy, které selhávají, zatímco interní IP adresy fungují, ukazují na zásady resolveru, ne na směrování. Windows rozhoduje DNS pro každý jmenný prostor pomocí tabulky zásad překladu názvů, která je nezávislá na směrovací tabulce:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKdyž pravidlo odpovídá *.corp.example, dotazy pro tento jmenný prostor jdou na DNS servery tunelu, i když datová cesta k těmto serverům zůstává v režimu rozděleného tunelu na fyzickém adaptéru. To je záměr a proto test v prohlížeči, který otevře veřejný web, neříká o interních názvech nic. Pokud adaptér vypisuje očekávané servery, ale vyhledávání přesto jde jinam, porovnejte pořadí pravidel NRPT a zkontrolujte, zda jako první neodpovídá konkrétnější jmenný prostor.
Ověřte toky a pak rozhodněte, co jste vlastně žádali
Projděte cíle v pevném pořadí, aby byly výsledky srovnatelné mezi počítači: veřejná adresa, interní adresa, interní název a jedna záměrná výjimka, například místní tiskárna nebo videohovor. Poznamenejte rozhraní a zdrojovou adresu, které Find-NetRoute pro každý vrátí. Po každé změně zásad se znovu připojte a zopakujte stejné čtyři kontroly; směrovací tabulka po opětovném připojení je jediný důkaz, že nový profil vstoupil v platnost.
Pak oddělte směrování od vynucení. Vynucené tunelování preferuje tunel pro pokrytý provoz, dokud je nahoru. Není to kill switch. Pokud je požadavek, aby při pádu tunelu nic neopustilo počítač, musí to přijít z blokujícího návrhu: profil brány firewall vázaný na stav tunelu, profil stále zapnutý s filtry provozu nebo vlastní volba zavření při selhání v klientském programu dodavatele. Vynucené tunelování také musí nechat vlastní adresu serveru VPN dostupnou mimo tunel, a blokovat ji ve jménu „vynucení všeho“ je spolehlivý způsob, jak se zamknout z připojení, které se snažíte vynutit.
Než něco změníte, projděte tento seznam. Každá položka, která selže, zužuje, kde je skutečný problém.
- Název a rozsah profilu potvrzeny, s
-AllUserConnectionpro profily pro celý počítač. SplitTunnelingpřečteno a bráno jako konfigurace, nikoli jako důkaz pokrytí.- Trasy adaptéru tunelu vypsány zvlášť pro IPv4 a IPv6.
Find-NetRoutespuštěno pro jeden veřejný, jeden interní a jeden výjimečný cíl.- Pravidla NRPT zkontrolována před tím, než obviníte trasy ze selhání názvu.
- Požadavek na blokování znovu přečten: preferované směrování není totéž jako vynucené blokování.
Rozhodnutí o plném nebo rozděleném tunelu patří tomu, kdo profil vlastní, a poznámky Microsoftu ke směrování popisují chování, které Windows uplatní, když je profil nastaví. Microsoft: vynucené a rozdělené tunelování je odkaz, který mám otevřený, když čtu výstup.