Hoe u controleert wat een VPN op Windows echt routeert in PowerShell
Een verbonden VPN-tegel bewijst geen dekking. Lees de opgeslagen profielvlag, de actieve routetabel en de NRPT-regels in deze volgorde.
Ik verbond de VPN-client op een Windows 11-laptop, de tegel ging naar Connected, een interne bestandsshare opende en een openbare site laadde nog steeds rechtstreeks via de Wi-Fi van kantoor. Die mix lijkt op een kapotte tunnel. Het is de normale uitvoer van een profiel dat een deel van het verkeer via de VPN stuurt en de rest op de fysieke adapter laat. Gedwongen tunneling verandert welke standaardroute Windows verkiest; het verwijdert geen specifiekere routes en belooft niet dat verkeer stopt wanneer de verbinding wegvalt. Wat volgt is de volgorde die ik doorloop wanneer een client dekking claimt: clientstatus, opgeslagen profiel, toegepaste routes, resolver en dan echte stromen.
Begin bij de client en stop er dan mee hem te vertrouwen
De client is alleen de juiste plek om te beginnen omdat hij zegt welk profiel actief is. Open de verbindingseigenschappen en noteer de exacte profielnaam, of die voor de huidige gebruiker of voor iedereen op de machine is gemaakt, en welke adapter na het verbinden in ncpa.cpl verschijnt. Op mijn testlaptop droeg de adapter de profielnaam, wat de route-uitvoer makkelijk leesbaar maakte. Op andere machines verschijnt hij als een WAN Miniport-vermelding en de naam zegt u niets.
Wat de client u niet kan vertellen, is dekking. Een verbonden tegel beschrijft de staat van de tunnel, niet een inventaris van bestemmingen. Clients van derden houden ook hun eigen configuratie bij, dus het native Windows-profiel, en elke eigenschap die u eruit leest, heeft misschien niets te maken met wat die client heeft geïnstalleerd. Als de VPN via AnyConnect, OpenVPN GUI, WireGuard of een leveranciersagent kwam, gelden de PowerShell-controles hieronder meestal niet en moet u in plaats daarvan de eigen split-tunnel- en routinginstellingen van die client lezen.
Lees het opgeslagen profiel, niet de tegel
Voor een native Windows-profiel (IKEv2, L2TP, SSTP of een door MDM gepusht profiel) is de opgeslagen split-tunnelbeslissing één eigenschap:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixVoeg -AllUserConnection toe wanneer het profiel voor iedereen op het apparaat is gemaakt. Zonder dat leest u de lijst van de huidige gebruiker, die leeg kan zijn of een andere vermelding met een vergelijkbare naam kan bevatten. De waarde False in SplitTunneling betekent dat het profiel als volledige tunnel is opgeslagen: Windows installeert een standaardroute via de VPN-adapter. True betekent split-tunnel, en de dekking hangt dan volledig af van de routes en naamoplossingsregels die dat profiel pusht.
Behandel die waarde als configuratie, niet als waarneming. Hij legt vast wat het profiel bij het verbinden vroeg. Windows kan met andere toegepaste routes eindigen door een specifiekere route van een andere interface, een beleidsinstelling of een restant van een eerdere verbinding, dus de boolean beslecht de vraag nooit alleen.
Vergelijk de opgeslagen waarde met de toegepaste routetabel
List na het verbinden de routes op de tunneladapter in plaats van de hele tabel door te scrollen:
$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 is de nuttige helft. Het beantwoordt de vraag die de client nooit beantwoordt: voor deze bestemming, welke interface en welk bronadres zal Windows werkelijk gebruiken? Voer het uit voor een interne host, een openbare host en alles wat u als bewuste uitzondering beschouwt. Een volledige-tunnelprofiel hoort de tunnelinterface voor het openbare adres te tonen. Een split-tunnelprofiel toont daar meestal de fysieke adapter, terwijl interne prefixen nog steeds naar de VPN worden opgelost.
Twee valkuilen verklaren de meeste meldingen «het routeert de verkeerde kant op». Het meest specifieke prefix wint altijd, dus een /24 op de fysieke adapter verslaat een standaardroute op de VPN hoe laag de metriek van de tunnel ook is. De metriek beslecht alleen gelijke standen tussen routes voor hetzelfde prefix. En IPv4 en IPv6 worden apart beslist: een profiel dat 0.0.0.0/0 dekt, kan IPv6 op de lokale link laten, waardoor een dual-stack-site half getunneld lijkt. Controleer Get-NetRoute -AddressFamily IPv6 voordat u concludeert dat de tunnel in orde is.
| 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 |
Controleer naamoplossing apart met de NRPT
Interne namen die falen terwijl interne IP-adressen werken, wijzen op resolverbeleid, niet op routing. Windows beslist DNS per naamruimte via de tabel voor naamoplossingsbeleid, die onafhankelijk is van de routetabel:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexWanneer een regel overeenkomt met *.corp.example, gaan query's voor die naamruimte naar de DNS-servers van de tunnel, zelfs als het datapad naar die servers in split-tunnelmodus op de fysieke adapter blijft. Dat is het ontwerp, en daarom zegt een browsertest die een openbare site opent niets over interne namen. Als de adapter de verwachte servers vermeldt maar opzoekingen toch elders heen gaan, vergelijk dan de volgorde van de NRPT-regels en controleer of een specifiekere naamruimte als eerste matcht.
Verifieer de stromen en bepaal dan wat u eigenlijk hebt gevraagd
Loop de bestemmingen in een vaste volgorde door zodat resultaten tussen machines vergelijkbaar zijn: een openbaar adres, een intern adres, een interne naam en één bewuste uitzondering zoals een lokale printer of een videogesprek. Noteer de interface en het bronadres dat Find-NetRoute voor elk teruggeeft. Na elke beleidswijziging verbindt u opnieuw en herhaalt u dezelfde vier controles; de routetabel na het opnieuw verbinden is het enige bewijs dat het nieuwe profiel inging.
Scheid daarna routing van handhaving. Gedwongen tunneling verkiest de tunnel voor gedekt verkeer zolang die omhoog staat. Het is geen kill switch. Als de eis is dat er niets de machine verlaat wanneer de tunnel valt, moet dat uit een blokkerend ontwerp komen: een firewallprofiel gekoppeld aan de tunnelstatus, een altijd-aan-profiel met verkeersfilters of de eigen sluit-bij-fout-optie van de leveranciersclient. Gedwongen tunneling moet ook het eigen adres van de VPN-server buiten de tunnel bereikbaar laten, en dat blokkeren in naam van «alles forceren» is een betrouwbare manier om uzelf buiten de verbinding te sluiten die u probeert af te dwingen.
Voordat u iets wijzigt, loopt u deze lijst door. Elk item dat faalt, vernauwt waar het echte probleem zit.
- Profielnaam en -bereik bevestigd, met
-AllUserConnectionvoor profielen voor de hele machine. SplitTunnelinggelezen en behandeld als configuratie, niet als bewijs van dekking.- Tunneladapterroutes apart vermeld voor IPv4 en IPv6.
Find-NetRouteuitgevoerd voor één openbare, één interne en één uitzonderingsbestemming.- NRPT-regels gecontroleerd voordat de routes de schuld kregen van een naamfout.
- Blokkeringsvereiste opnieuw gelezen: voorkeursrouting is niet hetzelfde als afgedwongen blokkering.
De beslissing over volledige of split-tunnel hoort bij wie het profiel bezit, en Microsofts routingnotities beschrijven het gedrag dat Windows implementeert wanneer een profiel het instelt. Microsoft: gedwongen en split-tunneling is de referentie die ik open houd terwijl ik de uitvoer lees.