Ako zistiť, čo VPN v Windows naozaj smeruje v PowerShelli
Pripojená dlaždica VPN nepreukazuje pokrytie. Prečítajte uloženú vlajku profilu, živú tabuľku trás a pravidlá NRPT v tomto poradí.
Pripojil som klienta VPN na notebooku s Windows 11, dlaždica prešla do stavu Connected, otvorilo sa interné zdieľanie súborov a verejná lokalita sa stále načítavala priamo z kancelárskej Wi-Fi. Táto zmes vyzerá ako pokazený tunel. Je to normálny výstup profilu, ktorý časť prevádzky posiela cez VPN a zvyšok necháva na fyzickom adaptéri. Vynútené tunelovanie mení, ktorú predvolenú trasu Windows preferuje; nemaže konkrétnejšie trasy a nesľubuje, že prevádzka po prerušení spojenia prestane. Nasleduje poradie, ktoré prechádzam, keď klient tvrdí pokrytie: stav klienta, uložený profil, aplikované trasy, resolver a potom skutočné toky.
Začnite pri klientovi a potom mu prestaňte dôverovať
Klient je správne miesto na začiatok len preto, že vám povie, ktorý profil je aktívny. Otvorte vlastnosti pripojenia a poznamenajte si presný názov profilu, či bol vytvorený pre aktuálneho používateľa alebo pre všetkých na počítači, a ktorý adaptér sa po pripojení objaví v ncpa.cpl. Na mojom testovacom notebooku adaptér niesol názov profilu, čo uľahčilo čítanie výstupu trás. Na iných počítačoch sa zobrazí ako položka WAN Miniport a názov vám nič nepovie.
Čo vám klient nevie povedať, je pokrytie. Pripojená dlaždica opisuje stav tunela, nie zoznam cieľov. Klienti tretích strán si tiež držia vlastnú konfiguráciu, takže natívny profil Windows a každá vlastnosť, ktorú z neho prečítate, nemusí mať nič spoločné s tým, čo ten klient nainštaloval. Ak VPN prišla cez AnyConnect, OpenVPN GUI, WireGuard alebo agenta dodávateľa, nižšie uvedené kontroly PowerShellu väčšinou neplatia a mali by ste namiesto nich čítať vlastné nastavenia rozdeleného tunela a smerovania tohto klienta.
Čítajte uložený profil, nie dlaždicu
Pre natívny profil Windows (IKEv2, L2TP, SSTP alebo profil pretlačený MDM) je uložené rozhodnutie o rozdelenom tuneli jediná vlastnosť:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixPridajte -AllUserConnection, keď bol profil vytvorený pre všetkých na zariadení. Bez toho čítate zoznam aktuálneho používateľa, ktorý môže byť prázdny alebo obsahovať inú položku s podobným názvom. Hodnota False v SplitTunneling znamená, že profil bol uložený ako plný tunel: Windows nainštaluje predvolenú trasu cez adaptér VPN. True znamená rozdelený tunel a pokrytie potom úplne závisí od trás a pravidiel prekladu názvov, ktoré tento profil pretláča.
Berte túto hodnotu ako konfiguráciu, nie ako pozorovanie. Zaznamenáva, čo profil žiadal v čase pripojenia. Windows môže skončiť s odlišnými aplikovanými trasami pre konkrétnejšiu trasu iného rozhrania, nastavenie politiky alebo zvyškovú položku z predchádzajúceho pripojenia, takže boolean otázku sám nikdy nerozhodne.
Porovnajte uloženú hodnotu s aplikovanou tabuľkou trás
Po pripojení vypíšte trasy na adaptéri tunela namiesto prechádzania celej tabuľky:
$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žitočná polovica. Odpovedá na otázku, ktorú klient nikdy nezodpovie: pre tento cieľ, ktoré rozhranie a ktorú zdrojovú adresu Windows skutočne použije? Spustite ho pre interného hostiteľa, verejného hostiteľa a čokoľvek, čo považujete za zámernú výnimku. Profil plného tunela by mal pre verejnú adresu ukázať rozhranie tunela. Profil rozdeleného tunela tam zvyčajne ukazuje fyzický adaptér, zatiaľ čo interné prefixy sa stále prekladajú cez VPN.
Dve pasce vysvetľujú väčšinu hlásení „smeruje to zle“. Najšpecifickejší prefix vždy vyhrá, takže /24 na fyzickom adaptéri porazí predvolenú trasu na VPN, nech je metrika tunela akokoľvek nízka. Metrika len rozhoduje remízy medzi trasami s rovnakým prefixom. A IPv4 a IPv6 sa rozhodujú oddelene: profil, ktorý pokrýva 0.0.0.0/0, môže nechať IPv6 na lokálnom spoji, čím lokalita s dvoma zásobníkmi vyzerá na polovicu tunelovaná. Pred záverom, že tunel je v poriadku, skontrolujte Get-NetRoute -AddressFamily IPv6.
| 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 |
Preklad názvov skontrolujte oddelene pomocou NRPT
Interné názvy, ktoré zlyhávajú, zatiaľ čo interné IP adresy fungujú, ukazujú na politiku resolvera, nie na smerovanie. Windows rozhoduje DNS pre každý menný priestor cez tabuľku politiky prekladu názvov, ktorá je nezávislá od tabuľky trás:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKeď pravidlo zodpovedá *.corp.example, dopyty pre tento menný priestor idú na DNS servery tunela, aj keď dátová cesta k týmto serverom v režime rozdeleného tunela zostáva na fyzickom adaptéri. To je zámer a preto test v prehliadači, ktorý otvorí verejnú lokalitu, nehovorí o interných názvoch nič. Ak adaptér uvádza očakávané servery, ale vyhľadávanie ide stále inam, porovnajte poradie pravidiel NRPT a skontrolujte, či ako prvé nezodpovedá konkrétnejší menný priestor.
Overte toky a potom rozhodnite, čo ste vlastne žiadali
Prejdite ciele v pevnom poradí, aby boli výsledky porovnateľné medzi počítačmi: verejná adresa, interná adresa, interný názov a jedna zámerná výnimka, napríklad lokálna tlačiareň alebo videohovor. Poznamenajte rozhranie a zdrojovú adresu, ktoré Find-NetRoute vráti pre každý. Po každej zmene politiky sa znova pripojte a zopakujte tie isté štyri kontroly; tabuľka trás po opätovnom pripojení je jediný dôkaz, že nový profil nadobudol účinnosť.
Potom oddeľte smerovanie od vynucovania. Vynútené tunelovanie preferuje tunel pre pokrytú prevádzku, kým je hore. Nie je to kill switch. Ak je požiadavka, aby pri páde tunela nič neopustilo počítač, musí to prísť z blokujúceho návrhu: profil brány firewall viazaný na stav tunela, profil stále zapnutý s filtrami prevádzky alebo vlastná voľba zatvorenia pri zlyhaní v klientskom programe dodávateľa. Vynútené tunelovanie tiež musí nechať vlastnú adresu servera VPN dostupnú mimo tunela, a blokovať ju v mene „vynútenia všetkého“ je spoľahlivý spôsob, ako sa zamknúť z pripojenia, ktoré sa snažíte vynútiť.
Predtým, než niečo zmeníte, prejdite tento zoznam. Každá položka, ktorá zlyhá, zužuje, kde je skutočný problém.
- Názov a rozsah profilu potvrdené, s
-AllUserConnectionpre profily pre celý počítač. SplitTunnelingprečítané a brané ako konfigurácia, nie ako dôkaz pokrytia.- Trasy adaptéra tunela vypísané oddelene pre IPv4 a IPv6.
Find-NetRoutespustené pre jeden verejný, jeden interný a jeden výnimočný cieľ.- Pravidlá NRPT skontrolované predtým, než ste obvinili trasy zo zlyhania názvu.
- Požiadavka na blokovanie znovu prečítaná: preferované smerovanie nie je to isté ako vynútené blokovanie.
Rozhodnutie o plnom alebo rozdelenom tuneli patrí tomu, kto profil vlastní, a poznámky Microsoftu k smerovaniu opisujú správanie, ktoré Windows uplatní, keď ho profil nastaví. Microsoft: vynútené a rozdelené tunelovanie je odkaz, ktorý mám otvorený pri čítaní výstupu.