Com comprovar què encamina realment una VPN a Windows amb PowerShell
Una fitxa de VPN connectada no demostra la cobertura. Llegeix la marca desada del perfil, la taula de rutes en viu i les regles de NRPT en aquest ordre.
Vaig connectar el client VPN en un portàtil amb Windows 11, la fitxa va passar a Connectat, es va obrir un recurs compartit intern i un lloc públic encara es carregava directament des del Wi-Fi de l'oficina. Aquesta barreja sembla un túnel trencat. És la sortida normal d'un perfil que envia part del trànsit per la VPN i deixa la resta a l'adaptador físic. El tunelatge forçat canvia quina ruta per defecte prefereix Windows; no esborra les rutes més específiques ni promet que el trànsit s'aturi quan cau la connexió. El que segueix és l'ordre que faig servir quan un client afirma cobertura: estat del client, perfil desat, rutes aplicades, resolutor i després fluxos reals.
Comença pel client i deixa de confiar-hi
El client és el lloc correcte per començar només perquè et diu quin perfil és actiu. Obre les propietats de la connexió i anota el nom exacte del perfil, si es va crear per a l'usuari actual o per a tothom de la màquina, i quin adaptador apareix a ncpa.cpl després de connectar. Al meu portàtil de proves l'adaptador portava el nom del perfil, cosa que feia fàcil llegir la sortida de rutes. En altres màquines apareix com una entrada WAN Miniport i el nom no et diu res.
El que el client no et pot dir és la cobertura. Una fitxa connectada descriu l'estat del túnel, no un inventari de destinacions. Els clients de tercers també guarden la seva pròpia configuració, així que el perfil natiu de Windows, i cada propietat que en llegiràs, pot no tenir res a veure amb el que aquell client va instal·lar. Si la VPN va arribar per AnyConnect, OpenVPN GUI, WireGuard o un agent de proveïdor, les comprovacions de PowerShell d'aquí baix generalment no s'apliquen i hauries de llegir la configuració de túnel dividit i d'encaminament d'aquell client.
Llegeix el perfil desat, no la fitxa
Per a un perfil natiu de Windows (IKEv2, L2TP, SSTP o un que empeny MDM), la decisió desada de túnel dividit és una sola propietat:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixAfegeix -AllUserConnection quan el perfil es va crear per a tothom del dispositiu. Sense això llegeixes la llista de l'usuari actual, que pot ser buida o contenir una altra entrada amb un nom semblant. Un valor False a SplitTunneling vol dir que el perfil es va desar com a túnel complet: Windows instal·la una ruta per defecte a través de l'adaptador de la VPN. True vol dir túnel dividit, i aleshores la cobertura depèn totalment de les rutes i de les regles de resolució de noms que empeny aquest perfil.
Tracta aquest valor com a configuració, no com a observació. Enregistra què va demanar el perfil en connectar. Windows pot acabar amb rutes aplicades diferents, per una ruta més específica d'una altra interfície, una opció de política o una entrada sobrant d'una connexió anterior, així que el booleà no resol la qüestió tot sol.
Compara el valor desat amb la taula de rutes aplicada
Després de connectar, llista les rutes de l'adaptador del túnel en lloc de recórrer tota la taula:
$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 és la meitat útil. Respon la pregunta que el client no respon mai: per a aquesta destinació, quina interfície i quina adreça d'origen farà servir Windows realment? Executa'l per a un amfitrió intern, un amfitrió públic i qualsevol cosa que creguis una excepció deliberada. Un perfil de túnel complet hauria de mostrar la interfície del túnel per a l'adreça pública. Un perfil de túnel dividit normalment hi mostra l'adaptador físic mentre els prefixos interns encara es resolen per la VPN.
Dues trampes expliquen la majoria dels informes «encamina malament». El prefix més específic sempre guanya, així que un /24 a l'adaptador físic supera una ruta per defecte a la VPN per baixa que sigui la mètrica del túnel. La mètrica només desempata entre rutes del mateix prefix. I IPv4 i IPv6 es decideixen per separat: un perfil que cobreix 0.0.0.0/0 pot deixar IPv6 a l'enllaç local, cosa que fa que un lloc de doble pila sembli mig tunelat. Comprova Get-NetRoute -AddressFamily IPv6 abans de concloure que el túnel està bé.
| 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 |
Comprova la resolució de noms per separat amb NRPT
Els noms interns que fallen mentre les adreces IP internes funcionen apunten a la política del resolutor, no a l'encaminament. Windows decideix el DNS per espai de noms amb la taula de política de resolució de noms, que és independent de la taula de rutes:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexQuan una regla coincideix amb *.corp.example, les consultes d'aquell espai de noms van als servidors DNS del túnel encara que el camí de dades a aquests servidors es quedi a l'adaptador físic en mode túnel dividit. Aquest és el disseny, i per això una prova de navegador que obre un lloc públic no et diu res sobre els noms interns. Si l'adaptador llista els servidors esperats però les consultes continuen anant a un altre lloc, compara l'ordre de les regles NRPT i comprova si un espai de noms més específic coincideix primer.
Verifica els fluxos i després decideix què has demanat realment
Recorre les destinacions en un ordre fix perquè els resultats siguin comparables entre màquines: una adreça pública, una adreça interna, un nom intern i una excepció deliberada com una impressora local o una videotrucada. Anota la interfície i l'adreça d'origen que Find-NetRoute retorna per a cadascuna. Després de qualsevol canvi de política, reconnecta i repeteix les mateixes quatre comprovacions; la taula de rutes posterior a la reconnexió és l'única evidència que el nou perfil ha entrat en vigor.
Després separa l'encaminament de l'aplicació forçada. El tunelatge forçat prefereix el túnel per al trànsit cobert mentre és aixecat. No és un interruptor d'emergència. Si el requisit és que res surti de la màquina quan cau el túnel, això ha de venir d'un disseny de bloqueig: un perfil de tallafocs lligat a l'estat del túnel, un perfil sempre actiu amb filtres de trànsit o l'opció pròpia de tancament en fallada del client del proveïdor. El tunelatge forçat també ha de deixar l'adreça del mateix servidor VPN accessible fora del túnel, i bloquejar-la en nom de «forçar-ho tot» és una manera fiable de quedar-se fora de la connexió que intentes aplicar.
Abans de canviar res, repassa aquesta llista. Cada element que falla estreny on és el problema real.
- Nom i abast del perfil confirmats, amb
-AllUserConnectionper als perfils de tota la màquina. SplitTunnelingllegit i tractat com a configuració, no com a prova de cobertura.- Rutes de l'adaptador del túnel llistades per separat per a IPv4 i IPv6.
Find-NetRouteexecutat per a una destinació pública, una interna i una excepció.- Regles NRPT comprovades abans de culpar les rutes per una fallada de nom.
- Requisit de bloqueig rellegit: l'encaminament preferit no és el mateix que el bloqueig aplicat.
La decisió de túnel complet o dividit pertany a qui posseeix el perfil, i les notes d'encaminament de Microsoft descriuen el comportament que Windows implementa quan un perfil ho estableix. Microsoft: tunelatge forçat i dividit és la referència que mantinc oberta mentre llegeixo la sortida.