Kiel kontroli, kion VPN en Windows efektive enkursigas per PowerShell
Konektita VPN-kahelo ne pruvas kovradon. Legu la konservitan profilflagon, la aktualan vojregliston kaj la NRPT-regulojn en tiu ordo.
Mi konektis la VPN-klienton sur Windows 11 tekkomputilo, la kahelo iris al Konektita, interna dosierkunhavo malfermiĝis, kaj publika retejo ankoraŭ ŝargiĝis rekte el la oficeja Wi-Fi. Tiu miksaĵo aspektas kiel rompita tunelo. Ĝi estas la normala eligo de profilo, kiu sendas parton de la trafiko tra la VPN kaj lasas la reston sur la fizika adaptilo. Trudita tunelado ŝanĝas, kiun defaŭltan vojon Windows preferas; ĝi ne forigas pli specifajn vojojn kaj ne promesas, ke trafiko haltos kiam la konekto falas. Jen la ordo laŭ kiu mi laboras kiam kliento asertas kovradon: klienta stato, konservita profilo, aplikitaj vojoj, solvilo, poste realaj fluoj.
Komencu ĉe la kliento, poste ĉesu fidi ĝin
La kliento estas la ĝusta loko por komenci nur ĉar ĝi diras al vi, kiu profilo estas aktiva. Malfermu la konektajn ecojn kaj notu la precizan profilnomon, ĉu ĝi kreiĝis por la nuna uzanto aŭ por ĉiuj sur la maŝino, kaj kiun adaptilon montras ncpa.cpl post konekto. Sur mia testa tekkomputilo la adaptilo portis la profilnomon, kio faciligis legi la vojeligon. Sur aliaj maŝinoj ĝi aperas kiel WAN Miniport ero kaj la nomo diras al vi nenion.
Kion la kliento ne povas diri al vi estas kovrado. Konektita kahelo priskribas la staton de la tunelo, ne inventaron de celoj. Trialaj klientoj ankaŭ tenas sian propran agordon, do la denaska Windows-profilo, kaj ĉiu eco, kiun vi legos el ĝi, eble havas nenion komunan kun tio, kion tiu kliento instalas. Se la VPN venis per AnyConnect, OpenVPN GUI, WireGuard aŭ vendista agento, la subaj PowerShell-kontroloj plejparte ne validas kaj vi prefere legu la proprajn split-tunnel kaj enkursigajn agordojn de tiu kliento.
Legu la konservitan profilon, ne la kahelon
Por denaska Windows-profilo (IKEv2, L2TP, SSTP aŭ unu puŝita de MDM) la konservita split-tunnel-decidaĵo estas ununura eco:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixAldonu -AllUserConnection kiam la profilo kreiĝis por ĉiuj sur la aparato. Sen ĝi vi legas la liston de la nuna uzanto, kiu povas esti malplena aŭ teni alian eron kun simila nomo. Valoro False en SplitTunneling signifas, ke la profilo estis konservita kiel plena tunelo: Windows instalas defaŭltan vojon tra la VPN-adaptilo. True signifas split tunnel, kaj kovrado tiam tute dependas de la vojoj kaj nomosolvaj reguloj, kiujn tiu profilo puŝas.
Traktu tiun valoron kiel agordon, ne kiel observon. Ĝi registras kion la profilo petis ĉe konekto. Windows povas fini kun malsamaj aplikitaj vojoj, pro pli specifa vojo de alia interfaco, politika agordo aŭ resta ero el antaŭa konekto, do la bulea valoro neniam solvas la demandon sola.
Komparu la konservitan valoron kun la aplikita vojreglisto
Post konekto, listigu la vojojn sur la tunela adaptilo anstataŭ rulumi la tutan tabelon:
$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 estas la utila duono. Ĝi respondas la demandon, kiun la kliento neniam respondas: por ĉi tiu celo, kiun interfacon kaj kiun fontan adreson Windows efektive uzos? Rulu ĝin por interna gastiganto, publika gastiganto kaj io, kion vi kredas intenca escepto. Plena-tunela profilo devus montri la tunelan interfacon por la publika adreso. Split-tunela profilo kutime montras la fizikan adaptilon tie, dum internaj prefiksoj ankoraŭ solviĝas al la VPN.
Du kaptiloj klarigas plej multajn raportojn «ĝi enkursigas malĝuste». La plej specifa prefikso ĉiam venkas, do /24 sur la fizika adaptilo venkas defaŭltan vojon sur la VPN kiom ajn malalta estas la metriko de la tunelo. Metriko nur solvas egalecojn inter vojoj por la sama prefikso. Kaj IPv4 kaj IPv6 decidiĝas aparte: profilo, kiu kovras 0.0.0.0/0, povas lasi IPv6 sur la loka ligilo, kio igas du-stakan retejon aspekti duone tunelita. Kontrolu Get-NetRoute -AddressFamily IPv6 antaŭ ol konkludi, ke la tunelo estas en ordo.
| 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 |
Kontrolu nomsolvadon aparte per la NRPT
Internaj nomoj, kiuj malsukcesas dum internaj IP-adresoj funkcias, montras al solvila politiko, ne al enkursigo. Windows decidas DNS por ĉiu nomspaco per la tabulo de nomosolva politiko, kiu estas sendependa de la vojreglisto:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKiam regulo kongruas kun *.corp.example, demandoj por tiu nomspaco iras al la DNS-serviloj de la tunelo eĉ se la datenvojo al tiuj serviloj restas sur la fizika adaptilo en split-tunela reĝimo. Tio estas la dezajno, kaj tial retumila testo, kiu malfermas publikan retejon, diras al vi nenion pri internaj nomoj. Se la adaptilo listigas la atendatajn servilojn sed serĉoj ankoraŭ iras aliloken, komparu la ordon de la NRPT-reguloj kaj kontrolu, ĉu pli specifa nomspaco kongruas unue.
Kontrolu la fluojn, poste decidu, kion vi efektive petis
Trairu celojn laŭ fiksa ordo por ke rezultoj estu kompareblaj inter maŝinoj: publika adreso, interna adreso, interna nomo kaj unu intenca escepto kiel loka printilo aŭ videovoko. Notu la interfacon kaj fontan adreson, kiujn Find-NetRoute redonas por ĉiu. Post ajna politika ŝanĝo, rekonektu kaj ripetu la samajn kvar kontrolojn; la vojreglisto post rekonekto estas la sola pruvo, ke la nova profilo ekvalidis.
Poste apartigu enkursigon de plenumo. Trudita tunelado preferas la tunelon por kovrita trafiko dum ĝi staras. Ĝi ne estas mortiga ŝaltilo. Se la postulo estas, ke nenio forlasu la maŝinon kiam la tunelo falas, tio devas veni el blokada dezajno: fajroŝirma profilo ligita al tunela stato, ĉiam-ena profilo kun trafikfiltroj aŭ la propra fermo-ĉe-malsukceso opcio de la vendista kliento. Trudita tunelado ankaŭ devas lasi la propran adreson de la VPN-servilo atingebla ekster la tunelo, kaj bloki ĝin nome de «trudi ĉion» estas fidinda maniero ŝlosi vin ekster la konekto, kiun vi provas plenumi.
Antaŭ ol ŝanĝi ion, trairu ĉi tiun liston. Ĉiu ero, kiu malsukcesas, mallarĝigas, kie kuŝas la vera problemo.
- Profilnomo kaj amplekso konfirmitaj, kun
-AllUserConnectionuzita por tutmaŝinaj profiloj. SplitTunnelinglegita kaj traktita kiel agordo anstataŭ pruvo de kovrado.- Tuneladaptilaj vojoj listigitaj aparte por IPv4 kaj IPv6.
Find-NetRouterulita por unu publika, unu interna kaj unu escepta celo.- NRPT-reguloj kontrolitaj antaŭ ol kulpigi vojojn pro noma malsukceso.
- Blokada postulo relegita: preferata enkursigo ne samas kiel plenumita blokado.
La decido pri plena aŭ split tunelo apartenas al tiu, kiu posedas la profilon, kaj la enkursigaj notoj de Microsoft priskribas la konduton, kiun Windows plenumas kiam profilo ĝin agordas. Microsoft: trudita kaj split tunelado estas la referenco, kiun mi tenas malfermita legante la eligon.