Kuidas kontrollida, mida Windowsi VPN PowerShellis tegelikult marsruudib
Ühendatud VPN-paan ei tõesta katvust. Loe salvestatud profiili lippu, elavat marsruuditabelit ja NRPT reegleid selles järjekorras.
Ühendasin VPN-kliendi Windows 11 sülearvutis, paan läks olekusse Connected, sisemine failijagamine avanes ja avalik sait laadis endiselt otse kontori Wi-Fi kaudu. See segu näeb välja nagu katkine tunnel. See on profiili tavaline väljund, mis saadab osa liiklusest VPN-i kaudu ja jätab ülejäänu füüsilisele adapterile. Sunniviisiline tunnelimine muudab, millist vaikimisi marsruuti Windows eelistab; see ei kustuta täpsemaid marsruute ega luba, et liiklus peatub ühenduse katkedes. Järgnev on järjekord, mille järgi töötan, kui klient väidab katvust: kliendi olek, salvestatud profiil, rakendatud marsruudid, resolver ja siis tegelikud vood.
Alusta kliendist ja lõpeta selle usaldamine
Klient on õige alguskoht ainult sellepärast, et see ütleb, milline profiil on aktiivne. Ava ühenduse atribuudid ja pane kirja täpne profiilinimi, kas see loodi praegusele kasutajale või kõigile masinas, ja milline adapter ilmub pärast ühendamist ncpa.cpl-s. Minu test-sülearvutis kandis adapter profiilinime, mis tegi marsruudiväljundi lugemise lihtsaks. Teistel masinatel kuvatakse seda WAN Miniport kirjena ja nimi ei ütle sulle midagi.
Mida klient sulle öelda ei saa, on katvus. Ühendatud paan kirjeldab tunneli olekut, mitte sihtkohtade loendit. Kolmandate osapoolte kliendid hoiavad ka oma konfiguratsiooni, seega Windowsi natiivsel profiilil ja igal atribuudil, mida sa sellest loed, ei pruugi olla midagi pistmist sellega, mida see klient paigaldas. Kui VPN tuli AnyConnecti, OpenVPN GUI, WireGuardi või tarnija agendi kaudu, siis allolevad PowerShelli kontrollid enamasti ei kehti ja peaksid lugema selle kliendi enda split-tunneli ja marsruutimise seadeid.
Loe salvestatud profiili, mitte paani
Natiivse Windowsi profiili puhul (IKEv2, L2TP, SSTP või MDM-i poolt lükatud) on salvestatud split-tunneli otsus üks atribuut:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixLisa -AllUserConnection, kui profiil loodi kõigile seadmes. Ilma selleta loed praeguse kasutaja nimekirja, mis võib olla tühi või sisaldada teist sarnase nimega kirjet. Väärtus False kohas SplitTunneling tähendab, et profiil salvestati täistunnelina: Windows paigaldab VPN-adapteri kaudu vaikimisi marsruudi. True tähendab split-tunnelit ja katvus sõltub siis täielikult marsruutidest ja nimelahenduse reeglitest, mida see profiil lükkab.
Käsitle seda väärtust konfiguratsioonina, mitte vaatlusena. See registreerib, mida profiil ühendamise hetkel küsis. Windows võib jõuda erinevate rakendatud marsruutideni teise liidese täpsema marsruudi, poliitikaseade või eelmise ühenduse jääknurga tõttu, nii et tõeväärtus ei lahenda küsimust kunagi üksi.
Võrdle salvestatud väärtust rakendatud marsruuditabeliga
Pärast ühendamist loetle marsruudid tunnelil, mitte ära keri tervet tabelit:
$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 on kasulik pool. See vastab küsimusele, millele klient kunagi ei vasta: selle sihtkoha jaoks, millist liidest ja millist lähteaadressi Windows tegelikult kasutab? Käivita see sisemise hosti, avaliku hosti ja kõige jaoks, mida pead teadlikuks erandiks. Täistunneli profiil peaks avaliku aadressi jaoks näitama tunneli liidest. Split-tunneli profiil näitab seal tavaliselt füüsilist adapterit, samal ajal kui sisemised prefiksid lahenduvad endiselt VPN-i kaudu.
Kaks lõksu selgitavad enamikku aruandeid «marsruudib valesti». Kõige spetsiifilisem prefiks võidab alati, nii et füüsilise adapteri /24 lööb VPN-i vaikimisi marsruudi, ükskõik kui madal on tunneli meetrika. Meetrika otsustab ainult sama prefiksiga marsruutide vahelise viigi. Ja IPv4 ja IPv6 otsustatakse eraldi: profiil, mis katab 0.0.0.0/0, võib jätta IPv6 kohalikule lingile, mis teeb kahekihilise saidi poolenisti tunnelitud. Kontrolli Get-NetRoute -AddressFamily IPv6, enne kui järeldad, et tunnel on korras.
| 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 |
Kontrolli nimelahendust eraldi NRPT-ga
Sisemised nimed, mis ei tööta, samal ajal kui sisemised IP-aadressid töötavad, viitavad resolveri poliitikale, mitte marsruutimisele. Windows otsustab DNS-i nimeruumi kohta nimelahenduspoliitika tabeli kaudu, mis on marsruuditabelist sõltumatu:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKui reegel vastab *.corp.example, lähevad selle nimeruumi päringud tunneli DNS-serveritesse isegi siis, kui andmetee nende serveriteni jääb split-tunneli režiimis füüsilisele adapterile. See ongi kavatsus, ja seepärast ei ütle brauseri test, mis avab avaliku saidi, sisemiste nimede kohta midagi. Kui adapter loetleb oodatud serverid, aga otsingud lähevad ikkagi mujale, võrdle NRPT reeglite järjekorda ja kontrolli, kas esimesena sobib spetsiifilisem nimeruum.
Kontrolli vooge ja otsusta siis, mida sa tegelikult küsisid
Käi sihtkohad läbi fikseeritud järjekorras, et tulemused oleksid masinate vahel võrreldavad: avalik aadress, sisemine aadress, sisemine nimi ja üks teadlik erand, näiteks kohalik printer või videokõne. Pane kirja liides ja lähteaadress, mille Find-NetRoute igaühe jaoks tagastab. Pärast iga poliitikamuudatust ühenda uuesti ja korda samu nelja kontrolli; marsruuditabel pärast uuestiühendamist on ainus tõend, et uus profiil jõustus.
Seejärel eralda marsruutimine sunnist. Sunniviisiline tunnelimine eelistab tunnelit kaetud liikluse jaoks, kuni see püsti on. See ei ole kill switch. Kui nõue on, et midagi ei lahkuks masinast tunneli kukkudes, peab see tulema blokeerivast lahendusest: tunneliolekuga seotud tulemüüriprofiil, alati-ühendatud profiil liiklusfiltritega või tarnijakliendi enda sulgemine-vea-korral valik. Sunniviisiline tunnelimine peab jätma ka VPN-serveri enda aadressi väljaspool tunnelit kättesaadavaks, ja selle blokeerimine «kõige sundimise» nime all on usaldusväärne viis end lukustada välja ühendusest, mida proovid kehtestada.
Enne kui midagi muudad, käi see nimekiri läbi. Iga ebaõnnestuv punkt kitsendab, kus tegelik probleem asub.
- Profiili nimi ja ulatus kinnitatud,
-AllUserConnectionkasutatud masinaüleste profiilide jaoks. SplitTunnelingloetud ja käsitletud konfiguratsioonina, mitte katvuse tõestusena.- Tunneliadapteri marsruudid loetletud eraldi IPv4 ja IPv6 jaoks.
Find-NetRoutekäivitatud ühe avaliku, ühe sisemise ja ühe erandsihtkoha jaoks.- NRPT reeglid kontrollitud enne, kui marsruute nimevea eest süüdistati.
- Blokeerimisnõue uuesti loetud: eelistatud marsruutimine ei ole sama mis kehtestatud blokeerimine.
Täis- või split-tunneli otsus kuulub profiili omanikule ja Microsofti marsruudimärkmed kirjeldavad käitumist, mida Windows rakendab, kui profiil selle seab. Microsoft: sunnitud ja split-tunnelimine on viide, mida hoian väljundit lugedes lahti.