Cum verificați ce direcționează de fapt un VPN în Windows în PowerShell

Am conectat clientul VPN pe un laptop cu Windows 11, placa a trecut în Connected, s-a deschis o partajare internă de fișiere și un site public se încărca în continuare direct din Wi-Fi-ul biroului. Acest amestec arată ca un tunel spart. Este ieșirea normală a unui profil care trimite o parte din trafic prin VPN și lasă restul pe adaptorul fizic. Tunelarea forțată schimbă ce rută implicită preferă Windows; nu șterge rutele mai specifice și nu promite că traficul se oprește când conexiunea cade. Urmează ordinea pe care o parcurg când un client susține că are acoperire: starea clientului, profilul salvat, rutele aplicate, resolverul și apoi fluxurile reale.

Începeți cu clientul, apoi încetați să aveți încredere în el

Clientul este locul potrivit de început doar pentru că vă spune ce profil este activ. Deschideți proprietățile conexiunii și notați numele exact al profilului, dacă a fost creat pentru utilizatorul curent sau pentru toți de pe mașină, și ce adaptor apare în ncpa.cpl după conectare. Pe laptopul meu de test adaptorul purta numele profilului, ceea ce făcea ieșirea rutelor ușor de citit. Pe alte mașini apare ca o intrare WAN Miniport, iar numele nu vă spune nimic.

Ce nu vă poate spune clientul este acoperirea. O placă conectată descrie starea tunelului, nu un inventar al destinațiilor. Clienții terți își păstrează și propria configurație, așa că profilul nativ Windows, și fiecare proprietate pe care o veți citi din el, pot să nu aibă nicio legătură cu ce a instalat acel client. Dacă VPN-ul a venit prin AnyConnect, OpenVPN GUI, WireGuard sau un agent al furnizorului, verificările PowerShell de mai jos nu se aplică în general și ar trebui să citiți în schimb setările proprii de split-tunnel și rutare ale acelui client.

Citiți profilul salvat, nu placa

Pentru un profil nativ Windows (IKEv2, L2TP, SSTP sau unul împins de MDM), decizia salvată de split-tunnel este o singură proprietate:

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Adăugați -AllUserConnection când profilul a fost creat pentru toți de pe dispozitiv. Fără el citiți lista utilizatorului curent, care poate fi goală sau poate conține o altă intrare cu nume similar. Valoarea False în SplitTunneling înseamnă că profilul a fost salvat ca tunel complet: Windows instalează o rută implicită prin adaptorul VPN. True înseamnă split tunnel, iar acoperirea depinde atunci în întregime de rutele și regulile de rezolvare a numelor pe care le împinge acel profil.

Tratați acea valoare ca pe o configurație, nu ca pe o observație. Ea înregistrează ce a cerut profilul la conectare. Windows poate ajunge cu rute aplicate diferite, din cauza unei rute mai specifice a altui interfațe, a unei setări de politică sau a unei intrări rămase de la o conexiune anterioară, așa că valoarea booleană nu rezolvă niciodată singură întrebarea.

Comparați valoarea salvată cu tabelul de rute aplicat

După conectare, listați rutele de pe adaptorul tunelului în loc să derulați tot tabelul:

$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 1

Find-NetRoute este jumătatea utilă. Răspunde la întrebarea la care clientul nu răspunde niciodată: pentru această destinație, ce interfață și ce adresă sursă va folosi Windows de fapt? Rulați-l pentru un host intern, un host public și orice considerați o excepție deliberată. Un profil de tunel complet ar trebui să arate interfața tunelului pentru adresa publică. Un profil split tunnel arată de obicei adaptorul fizic acolo, în timp ce prefixele interne se rezolvă în continuare prin VPN.

Două capcane explică majoritatea rapoartelor «dirijează în direcția greșită». Prefixul cel mai specific câștigă întotdeauna, așa că un /24 pe adaptorul fizic bate o rută implicită pe VPN oricât de mică ar fi metrica tunelului. Metrica doar departajează rutele cu același prefix. Iar IPv4 și IPv6 sunt decise separat: un profil care acoperă 0.0.0.0/0 poate lăsa IPv6 pe legătura locală, ceea ce face un site dual-stack să pară pe jumătate tunelat. Verificați Get-NetRoute -AddressFamily IPv6 înainte de a concluziona că tunelul este în regulă.

Verificați rezolvarea numelor separat cu NRPT

Numele interne care eșuează în timp ce adresele IP interne funcționează indică politica resolverului, nu rutarea. Windows decide DNS pe spațiu de nume prin tabelul de politici de rezolvare a numelor, independent de tabelul de rute:

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Când o regulă corespunde cu *.corp.example, interogările pentru acel spațiu de nume merg la serverele DNS ale tunelului chiar dacă calea de date către acele servere rămâne pe adaptorul fizic în modul split tunnel. Acesta este proiectul și de aceea un test de browser care deschide un site public nu vă spune nimic despre numele interne. Dacă adaptorul listează serverele așteptate, dar căutările merg în altă parte, comparați ordinea regulilor NRPT și verificați dacă un spațiu de nume mai specific se potrivește primul.

Verificați fluxurile, apoi decideți ce ați cerut de fapt

Parcurgeți destinațiile într-o ordine fixă pentru ca rezultatele să fie comparabile între mașini: o adresă publică, o adresă internă, un nume intern și o excepție deliberată, cum ar fi o imprimantă locală sau un apel video. Notați interfața și adresa sursă pe care Find-NetRoute le returnează pentru fiecare. După orice schimbare de politică, reconectați-vă și repetați aceleași patru verificări; tabelul de rute după reconectare este singura dovadă că noul profil a intrat în vigoare.

Apoi separați rutarea de aplicare. Tunelarea forțată preferă tunelul pentru traficul acoperit cât timp acesta este activ. Nu este un kill switch. Dacă cerința este ca nimic să nu părăsească mașina când tunelul cade, aceasta trebuie să vină dintr-un proiect de blocare: un profil de firewall legat de starea tunelului, un profil mereu activ cu filtre de trafic sau opțiunea proprie de închidere la eșec a clientului furnizorului. Tunelarea forțată trebuie, de asemenea, să lase adresa serverului VPN accesibilă în afara tunelului, iar blocarea ei în numele „forțării a tot” este o modalitate sigură de a vă bloca în afara conexiunii pe care încercați să o impuneți.

Înainte de a schimba ceva, parcurgeți această listă. Fiecare element care eșuează restrânge unde se află problema reală.

• Numele și domeniul profilului confirmate, cu -AllUserConnection pentru profilurile la nivel de mașină.
• SplitTunneling citit și tratat ca configurație, nu ca dovadă a acoperirii.
• Rutele adaptorului tunelului listate separat pentru IPv4 și IPv6.
• Find-NetRoute rulat pentru o destinație publică, una internă și una de excepție.
• Regulile NRPT verificate înainte de a da vina pe rute pentru un eșec de nume.
• Cerința de blocare recitită: rutarea preferată nu este același lucru cu blocarea aplicată.

Decizia de tunel complet sau split aparține proprietarului profilului, iar notele de rutare ale Microsoft descriu comportamentul pe care Windows îl implementează când un profil îl setează. Microsoft: tunelare forțată și split este referința pe care o țin deschisă în timp ce citesc ieșirea.