Hoe't jo kontrolearje kinne wat in VPN op Windows yn PowerShell eins rûtelelet
In ferbûn VPN-tegel bewiist gjin dekking. Lês de bewarre profylflagge, de libbene rûtetabel en de NRPT-regels yn dizze folchoarder.
Ik ferbûn de VPN-klant op in Windows 11-laptop, de tegel gie nei Connected, in ynterne bestandieling iepene, en in iepenbiere side laden noch streekrjocht fan it kantoar-Wi-Fi. Dy miks liket op in brutsen tunnel. It is de normale útkomst fan in profyl dat in part fan it ferkear troch de VPN stjoert en de rest op 'e fysike adapter lit. Twongen tunneling feroaret hokker standertrûte Windows foarkar hat; it smyt gjin spesifiker rûtes fuort en it belooft net dat ferkear stopt as de ferbining falt. Wat folget is de folchoarder dy't ik oanhald as in klant dekking beweart: klantsteat, bewarre profyl, tapaste rûtes, resolvers, en dan echte streams.
Begin by de klant, en fertrou it dan net mear
De klant is it juste plak om te begjinnen allinnich om't er seit hokker profyl aktyf is. Iepenje de ferbiningseigenskippen en skriuw de krekte profylnamme op, oft dy foar de hjoeddeiske brûker of foar elkenien op 'e masine makke is, en hokker adapter nei it ferbinen yn ncpa.cpl ferskynt. Op myn testlaptop droech de adapter de profylnamme, wat de rûte-útjefte maklik lêsber makke. Op oare masines ferskynt er as in WAN Miniport-ynstjoering en de namme fertelt jo neat.
Wat de klant jo net fertelle kin, is dekking. In ferbûn tegel beskriuwt de steat fan 'e tunnel, net in ynventaris fan bestimmingen. Tredde-partijklanten hâlde ek har eigen konfiguraasje by, dat it natige Windows-profyl, en elke eigenskip dy't jo derút lêze sille, kin neat te krijen hawwe mei wat dy klant ynstallearre hat. As de VPN kaam fia AnyConnect, OpenVPN GUI, WireGuard of in leveransier-agent, dan jilde de PowerShell-kontrôles hjirûnder meastentiids net en moatte jo leaver de eigen split-tunnel- en rûte-ynstellingen fan dy klant lêze.
Lês it bewarre profyl, net de tegel
Foar in natige Windows-profyl (IKEv2, L2TP, SSTP of ien dy't troch MDM skood wurdt) is de bewarre split-tunnel-beslissing ien eigenskip:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixFoegje -AllUserConnection ta as it profyl foar elkenien op it apparaat makke is. Sûnder dat lêze jo de list fan 'e hjoeddeiske brûker, dy't leech wêze kin of in oare ynstjoering mei in ferlykbere namme befetsje kin. In wearde False yn SplitTunneling betsjut dat it profyl as in folsleine tunnel bewarre is: Windows ynstallearret in standertrûte troch de VPN-adapter. True betsjut split tunnel, en dekking hinget dan folslein ôf fan 'e rûtes en namme-oplossingsregels dy't dat profyl skoot.
Behannelje dy wearde as konfiguraasje, net as observaasje. It registrearret wat it profyl by it ferbinen frege. Windows kin einigje mei oare tapaste rûtes, troch in spesifikere rûte fan in oare interface, in beliedsyynde of in oerbliuwsel fan in eardere ferbining, dat de Boolean beslist de fraach net allinnich.
Fergelykje de bewarre wearde mei de tapaste rûtetabel
Nei it ferbinen, list de rûtes op 'e tunneladapter op ynstee fan de hiele tabel troch te skowen:
$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 helte. It beantwurdet de fraach dy't de klant nea beantwurdet: foar dizze bestimming, hokker interface en hokker boarneadres sil Windows echt brûke? Rinn it foar in ynterne host, in iepenbiere host en alles wat jo as in bewuste útsûndering beskôgje. In folsleine-tunnelprofyl moat de tunnelinterface foar it iepenbiere adres sjen litte. In split-tunnelprofyl lit dêr meastentiids de fysike adapter sjen, wylst ynterne foarheaksels noch altyd nei de VPN oplosse.
Twa fallen ferklearje de measte rapporten «it rûtelet ferkeard». It meast spesifike foarheaksel wint altyd, dat in /24 op 'e fysike adapter ferslacht in standertrûte op 'e VPN, hoe leech de metyk fan 'e tunnel ek is. Metyk beslist allinnich gelykens tusken rûtes foar itselde foarheaksel. En IPv4 en IPv6 wurde apart besletten: in profyl dat 0.0.0.0/0 dekt kin IPv6 op 'e lokale keppeling litte, wat in dûbel-stack-side heal-tunnele ferskine lit. Kontrolearje Get-NetRoute -AddressFamily IPv6 foar't jo konkludearje dat de tunnel goed 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 |
Kontrolearje namme-oplossing apart mei de NRPT
Ynterne nammen dy't mislearje wylst ynterne IP-adressen wurkje, wize op resolverbelled, net op rûteleas. Windows beslút DNS per nammeromte fia de tabel foar namme-oplossingsbelied, dy't ûnôfhinklik is fan 'e rûtetabel:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexAs in regel oerienkomt mei *.corp.example, gean fragen foar dy nammeromte nei de DNS-servers fan 'e tunnel, sels as it gegevenspaad nei dy servers op 'e fysike adapter bliuwt yn split-tunnelmodus. Dat is it ûntwerp, en dêrom fertelt in browsersaak dy't in iepenbiere side iepenet jo neat oer ynterne nammen. As de adapter de ferwachte servers listet mar sykjen noch altyd earne oars giet, fergelykje dan de folchoarder fan 'e NRPT-regels en kontrolearje oft in spesifikere nammeromte earst oerienkomt.
Kontrolearje de streams, en beslút dan wat jo eins frege hawwe
Wurksje troch bestimmingen yn in fêste folchoarder sadat resultaten oer masines fergelykber binne: in iepenbier adres, in yntern adres, in ynterne namme en ien bewuste útsûndering lykas in lokale printer of in fideo-oprop. Skriuw de interface en it boarneadres op dat Find-NetRoute foar elk weromjout. Nei elke beliedswiziging, ferbynje opnij en werhelje deselde fjouwer kontrôles; de rûtetabel nei it opnij ferbinen is it iennige bewiis dat it nije profyl fan krêft waard.
Skied dan rûteleas fan hanthavening. Twongen tunnelling foarkar de tunnel foar dekt ferkear wylst er omheech is. It is gjin kill switch. As de eask is dat neat de masine ferlit as de tunnel falt, moat dat fan in blokkearjend ûntwerp komme: in firewallprofyl bûn oan 'e tunnelsteat, in altyd-aan-profyl mei ferkearsfilters of de eigen slute-by-mislearring-opsje fan 'e leveransierklant. Twongen tunnelling moat ek it eigen adres fan 'e VPN-server bûten de tunnel berikber litte, en dat blokkearje yn 'e namme fan «alles twinge» is in betroubere manier om josels bûten de ferbining te sluten dy't jo besykje te hanthavenjen.
Foar't jo wat feroarje, rin dizze list troch. Elk item dat mislearret, ferhimmet wêr't it echte probleem sit.
- Profylnamme en omfang befêstige, mei
-AllUserConnectionbrûkt foar profilen foar de hiele masine. SplitTunnelinglêzen en as konfiguraasje behannele ynstee fan bewiis fan dekking.- Tunneladapterrûtes apart listet foar IPv4 en IPv6.
Find-NetRouterûn foar ien iepenbiere, ien ynterne en ien útsûnderingsbestimming.- NRPT-regels kontrolearre foar't rûtes de skuld krigen foar in namme-mislearring.
- Blokkearringseask opnij lêzen: foarkarrûteleas is net itselde as hanthavene blokkearring.
De beslissing oer folsleine of split tunnel heart by wa't it profyl besit, en de rûte-notysjes fan Microsoft beskriuwe it gedrach dat Windows útfiert as in profyl it ynstelt. Microsoft: twongen en split tunnelling is de referinsje dy't ik iepen hâld wylst ik de útjefte lês.