Kako preveriti, kaj VPN v Windowsu v resnici usmerja v PowerShellu
Povezana ploščica VPN ne dokazuje pokritosti. Preberite shranjeno zastavico profila, aktivno tabelo usmerjanja in pravila NRPT v tem vrstnem redu.
Povezal sem odjemalca VPN v prenosniku z Windows 11, ploščica je prešla v Connected, odprla se je interna skupna mapa in javno spletišče se je še vedno nalagalo neposredno prek pisarniškega Wi-Fi. Ta mešanica je videti kot pokvarjen tunel. Je običajen izhod profila, ki del prometa pošilja prek VPN, preostanek pa pusti na fizičnem vmesniku. Prisilno tuneliranje spremeni, kateri privzeti usmeritvi Windows daje prednost; ne briše natančnejših usmeritev in ne obljublja, da se bo promet ustavil ob prekinitvi povezave. Sledi vrstni red, ki ga uporabljam, ko odjemalec trdi, da ima pokritost: stanje odjemalca, shranjeni profil, uporabljene usmeritve, razreševalnik in nato resnični tokovi.
Začnite pri odjemalcu in mu nato prenehajte zaupati
Odjemalec je pravo mesto za začetek le zato, ker vam pove, kateri profil je aktiven. Odprite lastnosti povezave in zabeležite natančno ime profila, ali je bil ustvarjen za trenutnega uporabnika ali za vse na napravi, in kateri vmesnik se po povezavi pojavi v ncpa.cpl. V mojem testnem prenosniku je vmesnik nosil ime profila, kar je olajšalo branje izpisa usmeritev. Na drugih napravah se prikaže kot vnos WAN Miniport in ime vam ne pove nič.
Česar vam odjemalec ne more povedati, je pokritost. Povezana ploščica opisuje stanje tunela, ne seznama ciljev. Odjemalci tretjih ponudnikov tudi hranijo svojo konfiguracijo, zato izvorni profil Windows in vsaka lastnost, ki jo boste prebrali iz njega, morda nimata nič skupnega s tem, kar je namestil ta odjemalec. Če je VPN prišel prek AnyConnect, OpenVPN GUI, WireGuard ali agenta ponudnika, spodnje preveritve PowerShell večinoma ne veljajo in namesto tega preberite lastne nastavitve razdeljenega tunela in usmerjanja tega odjemalca.
Preberite shranjeni profil, ne ploščice
Za izvorni profil Windows (IKEv2, L2TP, SSTP ali profil, ki ga potisne MDM) je shranjena odločitev o razdeljenem tunelu ena sama lastnost:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixDodajte -AllUserConnection, ko je bil profil ustvarjen za vse na napravi. Brez tega berete seznam trenutnega uporabnika, ki je lahko prazen ali vsebuje drug vnos s podobnim imenom. Vrednost False v SplitTunneling pomeni, da je bil profil shranjen kot polni tunel: Windows namesti privzeto usmeritev prek vmesnika VPN. True pomeni razdeljeni tunel in pokritost je nato v celoti odvisna od usmeritev in pravil razreševanja imen, ki jih ta profil potiska.
To vrednost obravnavajte kot konfiguracijo, ne kot opažanje. Zapisuje, kaj je profil zahteval ob povezavi. Windows lahko konča z drugačnimi uporabljenimi usmeritvami zaradi natančnejše usmeritve drugega vmesnika, nastavitve pravilnika ali ostanka prejšnje povezave, zato logična vrednost nikoli ne odloči vprašanja sama.
Primerjajte shranjeno vrednost z uporabljeno tabelo usmerjanja
Po povezavi naštejte usmeritve na vmesniku tunela, namesto da bi drseli po celotni tabeli:
$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 uporabna polovica. Odgovori na vprašanje, na katero odjemalec nikoli ne odgovori: za ta cilj, kateri vmesnik in kateri izvorni naslov bo Windows dejansko uporabil? Zaženite ga za notranjega gostitelja, javnega gostitelja in vse, kar imate za namerno izjemo. Profil polnega tunela bi moral za javni naslov pokazati vmesnik tunela. Profil razdeljenega tunela tam običajno pokaže fizični vmesnik, medtem ko se notranje predpone še vedno razrešujejo v VPN.
Dve pasti pojasnita večino poročil »usmerja v napačno smer«. Najbolj natančna predpona vedno zmaga, zato /24 na fizičnem vmesniku premaga privzeto usmeritev na VPN, ne glede na to, kako nizka je metrika tunela. Metrika odloči le neodločeno med usmeritvami z isto predpono. In IPv4 ter IPv6 se odločata ločeno: profil, ki pokriva 0.0.0.0/0, lahko pusti IPv6 na lokalni povezavi, zaradi česar je spletišče z dvojnim skladom videti na pol tunelirano. Preden sklepate, da je tunel v redu, preverite 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 |
Razreševanje imen preverite ločeno z NRPT
Notranja imena, ki ne uspejo, medtem ko notranji naslovi IP delujejo, kažejo na pravilnik razreševalnika, ne na usmerjanje. Windows odloča o DNS za vsak imenski prostor prek tabele pravilnika razreševanja imen, ki je neodvisna od tabele usmerjanja:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKo se pravilo ujema z *.corp.example, gredo poizvedbe za ta imenski prostor na strežnike DNS tunela, tudi če podatkovna pot do teh strežnikov v načinu razdeljenega tunela ostane na fizičnem vmesniku. Takšna je zasnova in zato preizkus v brskalniku, ki odpre javno spletišče, ne pove ničesar o notranjih imenih. Če vmesnik navaja pričakovane strežnike, a iskanja še vedno gredo drugam, primerjajte vrstni red pravil NRPT in preverite, ali se prva ujema natančnejši imenski prostor.
Preverite tokove in nato odločite, kaj ste pravzaprav zahtevali
Pojdite skozi cilje v ustaljenem vrstnem redu, da bodo rezultati primerljivi med napravami: javni naslov, notranji naslov, notranje ime in ena namerna izjema, na primer lokalni tiskalnik ali video klic. Zabeležite vmesnik in izvorni naslov, ki ju Find-NetRoute vrne za vsakega. Po vsaki spremembi pravilnika se znova povežite in ponovite iste štiri preveritve; tabela usmerjanja po ponovni povezavi je edini dokaz, da je novi profil začel veljati.
Nato ločite usmerjanje od uveljavljanja. Prisilno tuneliranje daje prednost tunelu za pokrit promet, dokler je vzpostavljen. To ni kill switch. Če je zahteva, da ob padcu tunela nič ne zapusti naprave, mora to priti iz blokirne zasnove: profil požarnega zidu, vezan na stanje tunela, profil vedno vklopljen s filtri prometa ali lastna možnost zaprtja ob napaki pri odjemalcu ponudnika. Prisilno tuneliranje mora tudi pustiti naslov samega strežnika VPN dosegljiv zunaj tunela, blokiranje tega v imenu »vsiljevanja vsega« pa je zanesljiv način, da se zaklenete iz povezave, ki jo poskušate uveljaviti.
Preden karkoli spremenite, pojdite skozi ta seznam. Vsaka neuspešna postavka zoži, kje je resnična težava.
- Ime in obseg profila potrjena, z
-AllUserConnectionza profile na ravni naprave. SplitTunnelingprebran in obravnavan kot konfiguracija, ne kot dokaz pokritosti.- Usmeritve vmesnika tunela naštete ločeno za IPv4 in IPv6.
Find-NetRoutezagnan za en javni, en notranji in en izjemni cilj.- Pravila NRPT preverjena, preden so bile usmeritve obtožene za neuspeh imena.
- Zahteva po blokiranju znova prebrana: prednostno usmerjanje ni isto kot uveljavljeno blokiranje.
Odločitev o polnem ali razdeljenem tunelu pripada lastniku profila, in Microsoftove opombe o usmerjanju opisujejo vedenje, ki ga Windows izvede, ko ga profil nastavi. Microsoft: prisilno in razdeljeno tuneliranje je vir, ki ga imam odprtega med branjem izpisa.