VPN-ul din Windows preia tot traficul? Eliminați ruta implicită

Vă conectați la VPN-ul biroului și fiecare pagină din browser începe să treacă prin acea rețea: serverul de fișiere este rapid, tot restul este lent, filtrat sau dispărut. Clientul nu se comportă greșit; profilul a cerut un tunel complet. Comutatorul care îl oprește este o singură casetă într-un dialog pe care aplicația Setări modernă nu îl afișează, iar gateway-ul are din nou un cuvânt la fiecare conectare. Acest ghid urmează ordinea pe care interfața Windows o prezintă de fapt, apoi acoperă verificările care încă eșuează după ce tabelul de rute pare corect.

Începeți în proprietățile adaptorului, nu în Setări

Aplicația Setări listează profilul la Rețea și Internet, apoi la VPN, dar expune doar opțiuni generale. Decizia privind gateway-ul implicit locuiește pe adaptor. Deschideți lista clasică de adaptoare cu Win+R și ncpa.cpl, faceți clic dreapta pe conexiunea VPN, alegeți Proprietăți, selectați Protocolul Internet versiunea 4, alegeți din nou Proprietăți și apoi Avansat. Debifați Utilizați gateway-ul implicit în rețeaua la distanță și confirmați ieșirea din toate cele trei dialoguri.

Reconectați-vă înainte de testare, pentru că bifa se aplică la stabilirea tunelului, iar o sesiune existentă păstrează tabelul pe care l-a construit. Dacă adaptorul lipsește cât timp clientul este deconectat, conectați-vă o dată și redeschideți fereastra. Un client de la furnizor care instalează un adaptor TAP sau Wintun fără pagină de proprietăți IPv4 nu are deloc acest dialog; pentru acelea, aceeași decizie este o opțiune de tunel divizat în setările clientului însuși, iar caseta adaptorului este locul greșit unde să căutați.

Aceeași modificare din PowerShell

Pentru un profil creat în magazinul VPN din Windows, setarea poate fi scriptată, ceea ce este exact ce doriți dacă mașina este reconstruită des:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Acel cmdlet ajunge doar la profilurile din acel magazin. O conexiune adăugată de un client terț nu va apărea, iar comanda eșuează cu o eroare de nume care se citește ca o greșeală de tastare. Observați și ce nu face comutatorul: împiedică clientul să instaleze o rută implicită, dar nu elimină rutele pe care gateway-ul le împinge la conectare, așa că secțiunea următoare este încă necesară în multe rețele.

Când gateway-ul împinge din nou ruta implicită

Citiți mai întâi tabelul. Două intrări implicite cu metrici diferite înseamnă că modificarea profilului a funcționat și că ruta împinsă a înlocuit-o oricum:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Ștergeți ruta implicită care aparține tunelului și păstrați-o pe cea fizică. Folosiți indexul interfeței din a treia comandă, nu aliasul adaptorului, pentru că scripturile care transmit un alias se strică imediat ce numele afișat se schimbă:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

Ștergerea ia biroul cu ea, așa că adăugați la loc prefixele corporative prin gateway-ul tunelului. Aceasta este linia pe care oamenii o sar, și de aceea «VPN-ul a încetat să funcționeze» urmează unei modificări reușite de tunel divizat:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Nimic din toate acestea nu supraviețuiește unei reconectări, ceea ce este un comportament onest și nu un bug: adaptorul este reconstruit, iar clientul aplică din nou ceea ce profilul și gateway-ul au convenit. Dacă ruta implicită reapare de fiecare dată, gateway-ul este configurat să refuze tunelul divizat și va continua să o împingă sau va întrerupe sesiunea. Aceasta este politica operatorului de rețea, iar cererea aparține acolo, nu unui script local care luptă cu ea o dată pe conectare.

Verificați din nou DNS, IPv6 și metricile după o reconectare

Eliminarea unei rute implicite IPv4 nu dovedește nimic despre cealaltă familie sau despre rezolvarea numelor. Un tunel poate transporta IPv6 în timp ce ruta implicită IPv4 rămâne locală, iar o listă de resolvere împinsă poate menține numele interne funcționale în timp ce interogările care o folosesc merg pe altă cale. Verificați toate trei înainte de a considera totul gata:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Dacă starea revine la fiecare conectare, mutați comenzile într-o acțiune pe conectare în loc să editați tabelul manual: o sarcină planificată declanșată de evenimentul de conectare, sau setarea de tunel divizat a clientului însuși, acolo unde există. Țineți indexul interfeței într-o variabilă și căutați-l la execuție, pentru că se poate schimba atunci când se adaugă sau se scot adaptoare.

Decideți la ce ați renunțat

Traficul de internet local nu mai este inspectat sau filtrat de birou, iar orice este publicat doar prin tunel are acum nevoie de propria rută. Unele organizații consideră tunelul divizat o încălcare a politicii, așa că confirmați asta înainte de a modifica un dispozitiv gestionat; o rută implicită împinsă este uneori mecanismul de aplicare, nu un accident. Documentația Set-VpnConnection listează parametrul de tunel divizat și tipurile de profil cărora li se aplică.

Apoi verificați într-o ordine fixă: cine deține ruta implicită, navigarea obișnuită, un host corporativ după adresă, un nume intern și aceleași patru după o singură reconectare. Dacă navigarea funcționează și hostul corporativ eșuează, lipsește ruta de prefix, nu cea implicită pe care ați eliminat-o, iar asta este mult mai ieftin de reparat decât reconstruirea profilului.