Tunel divizat în Windows: căsuța de poartă și prefixul lipsă

Windows trimite tot prin tunel până debifați o căsuță, iar apoi prea puțin până adăugați subrețeaua. Ambele fac parte din aceeași modificare.

Tunelul raportează conectat și wiki-ul încă se încarcă. Apoi o descărcare se blochează și partajarea de pe raft nu mai răspunde. Tunelul și-a făcut treaba, iar profilul pur și simplu revendica fiecare destinație.

Windows tratează o conexiune VPN ca pe o decizie de rutare. Până când acea decizie nu este restrânsă, mașina se comportă ca și cum s-ar fi mutat la birou.

De ce un tunel funcțional pare o cădere

Un profil căruia i se permite să folosească poarta la distanță instalează o rută implicită prin tunel. Atunci fiecare destinație care nu este pe legătura locală iese prin paravanul de foc al biroului. Partajările locale nu mai răspund pentru că traficul lor călătorește acum pe alt continent și înapoi. Nimic din starea clientului nu reflectă asta.

Simptomele sunt înșelătoare intenționat. Rezolvarea numelor poate funcționa încă în timp ce partajarea expiră, sau invers. Utilizatorul raportează că VPN-ul este stricat, clientul raportează că el este în regulă, iar ambele afirmații sunt exacte.

Căsuța ascunsă în dialogul IPv4

Setarea se află câteva dialoguri mai adânc. Deschideți ncpa.cpl, faceți clic dreapta pe conexiune, apoi proprietățile IPv4, apoi Avansat, și debifați opțiunea care permite conexiunii să devină poarta implicită la distanță. Acea singură căsuță decide dacă profilul este un tunel complet. Tot restul din profil se aplică în continuare.

Comparați route print -4 înainte și după reconectare. Intrarea 0.0.0.0 care indica înainte tunelul ar trebui să fi dispărut, iar prefixele companiei ar trebui să fie încă acolo.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Schimbarea metricii interfeței nu este un substitut. O metrică decide doar între două rute implicite concurente, iar un client care își reinstalează propria rută implicită la fiecare conectare câștigă acea competiție indiferent de numărul setat.

Prefixul pe care nimeni nu l-a listat

Tunelul divizat expune exact prefixele înregistrate în profil. O subrețea de birou adăugată după scrierea profilului rămâne inaccesibilă în timp ce tunelul este perfect sănătos. Raportul ajunge atunci ca un singur server stricat, nu ca un VPN stricat.

O rută adăugată manual acoperă golul până când se schimbă adresa porții. Înregistrarea prefixului în conexiune este mai solidă, pentru că prefixul urmează atunci conexiunea în locul unei adrese ghicite.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Citiți lista salvată și tabelul activ împreună. Un prefix salvat poate exista în timp ce tabelul nu îl primește niciodată, ceea ce se întâmplă când un agent de administrare filtrează rutele după ce conexiunea urcă. Se întâmplă și invers, cu o rută din registru care indică un adaptor oprit. Niciuna dintre cele două vederi singură nu spune toată povestea.

Dovedirea rezultatului după o repornire

Urmăriți în ambele direcții și rezolvați după nume. O urmărire publică ar trebui să iasă prin furnizor, o urmărire internă ar trebui să intre în tunel, iar un gazdă internă ar trebui să răspundă după nume și nu doar după adresă.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Repetați după o deconectare, o reconectare și o repornire. Un prefix care supraviețuiește unei reconectări manuale și dispare după o repornire nu a fost niciodată salvat în profil.

Păstrați și imprimanta și NAS-ul în test, pentru că un tunel divizat care taie dispozitivele de lângă laptop a rezolvat o problemă creând una mai mică și mai iritantă. Referința Microsoft pentru Add-VpnConnectionRoute este locul unde verificați ortografia parametrilor față de versiunea modulului dumneavoastră.

Articole similare