De ce tabelul de rutare VPN din Windows afișează 0.0.0.0/1 și 128.0.0.0/1

Conectați-vă la un VPN Windows și deschideți tabelul de rutare, și două intrări ies în evidență: 0.0.0.0/1 și 128.0.0.0/1. Nu sunt o greșeală de tastare și nu înlocuiesc ruta implicită. Apariția lor depinde de o singură opțiune de profil, iar perechea este modul în care se construiește un tunel complet, nu o funcție de tunel divizat. Citiți opțiunea, prefixul și interfața împreună înainte de a schimba o singură linie.

Ce instalează opțiunea de gateway implicit

Opțiunea de profil care trimite totul prin tunel funcționează adăugând acele două prefixe. Scoateți opțiunea și ele dispar, lăsând o rută care acoperă doar subrețeaua oferită adaptorului tunelului. Căsuța de selectare controlează perechea; nu rescrie singura rută implicită. De aceea tabelul după debifare arată ca o rescriere parțială și nu ca o ștergere.

0.0.0.0/1 acoperă jumătatea inferioară a spațiului IPv4 și 128.0.0.0/1 jumătatea superioară, deci împreună acoperă fiecare adresă unicast. Fiecare este mai specifică decât o rută implicită 0.0.0.0/0, ceea ce înseamnă că potrivirea celui mai lung prefix trimite traficul obișnuit în tunel, în timp ce ruta fizică implicită rămâne unde era. Păstrarea acelei rute implicite nu este cosmetică: pachetele care învelește sarcina criptată sunt adresate adresei publice a serverului și trebuie să iasă prin adaptorul fizic. Înlocuiți ruta implicită în loc să o împărțiți, iar transportul tunelului însuși va încerca să intre în tunel, ceea ce este o buclă și nu o conexiune.

Prin urmare, o 0.0.0.0/0 literală care indică adaptorul VPN merită oprit. Clientul nativ nu scrie de obicei așa ceva, deci o rută manuală sau configurația altui client a modificat tabelul pe la spatele dumneavoastră. Găsiți-o înainte de a depana orice mai jos.

Demontarea este mai ieftină decât păstrarea unui gateway

Demontarea este argumentul practic pentru două intrări în loc de una. Clientul deține exact două rute cât timp este conectat și le șterge la deconectare, lăsând ce are adaptorul fizic în acel moment. Un client care ar fi înlocuit singura rută implicită ar trebui să-și amintească gateway-ul anterior, iar după o schimbare a bailului DHCP ar putea restabili unul care nu mai există. Două intrări proprii nu poartă o astfel de stare.

Alți clienți ajung la același design. Un profil OpenVPN cu redirect-gateway def1 instalează acele două prefixe în loc să șteargă ruta implicită, iar clientul Windows urmează același tipar din același motiv de rutare.

De aceea un tabel poate arăta ca un tunel complet când așteptați o divizare. Perechea este modul în care se construiește tunelul complet, nu dovada unei erori de tunel divizat. Dacă profilul este setat să folosească gateway-ul îndepărtat, totul este rutat, orice ar reuși să atingă o aplicație locală.

Cel mai lung prefix câștigă înaintea oricărei metrici

Lungimea prefixului decide căutarea înaintea oricărui alt câmp. Metrica doar departajează rutele cu prefix identic, deci o intrare /1 bate o rută implicită /0 chiar și când metrica ei este mai slabă. Legarea de interfață decide ce rămâne când două rute împart un prefix și Windows trebuie să aleagă ce adaptor trimite pachetul.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Un tabel de tunel divizat conține ruta fizică implicită, cele două jumătăți de rută implicită, ruta subrețelei tunelului și orice prefix de birou adăugat. Ruta fizică implicită poate sta pe o metrică mai mică sau mai mare în funcție de client și profil, iar cât timp perechea /1 există acea diferență nu schimbă nimic. Schimbă totul în momentul în care perechea este eliminată, iar atunci apare un gateway învechit sau o interfață greșită. Citiți tot tabelul și nu linia pe care vă așteptați să o schimbați.

Alegeți un singur proprietar pentru prefixul de birou

Pentru un tunel divizat, numiți doar prefixul care trebuie să folosească VPN-ul și alegeți o singură modalitate de a-l deține. Direcționarea rutei către adresa de tunel alocată funcționează până când adresa se schimbă, în timp ce legarea de interfață supraviețuiește schimbării adresei dar se rupe când indexul este realocat după reconstruirea profilului. Cmdlet-ul legat de profil evită ambele probleme, cu prețul de a avea nevoie de profil.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

Cmdlet-ul leagă prefixul de profilul numit, deci ruta apare cu conexiunea și pleacă împreună cu ea, ceea ce dorește un laptop administrat. O rută persistentă supraviețuiește repornirilor și supraviețuiește profilului care a motivat-o, și așa un VPN retras lasă intrări ani de zile. Alegeți o metodă pe prefix și notați alegerea, pentru că o rută persistentă plus o rută de profil pentru același prefix produc duplicate greu de descâlcit la demontare. Orice ați alege, proprietatea ar trebui să fie vizibilă în tichet și nu doar pe mașină.

Proprietatea este întrebarea la care răspunde această secțiune, nu sintaxa. Doi proprietari pentru un prefix este modul de eșec care merită evitat.

Verificați cu o destinație, nu cu un site web

Testați destinația care trebuie să traverseze tunelul, nu un site web care raportează o adresă de ieșire. Find-NetRoute returnează ruta selectată și adresa sursă, așa că vedeți dacă a câștigat prefixul de birou sau ruta fizică implicită, apoi deschideți partajarea în sine.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Un site cu adresa de ieșire este o verificare slabă, pentru că DNS, IPv6 și un proxy de browser pot trimite fiecare acea cerere pe o cale diferită. IPv4 și IPv6 au și setări separate în același dialog, iar golirea unei casete lasă cealaltă familie neatinsă, deci o mașină cu stivă dublă poate duce IPv6 prin tunel în timp ce IPv4 urmează ruta divizată. Verificați ambele familii înainte de a numi profilul divizat. Dacă ruta este corectă și serviciul tot eșuează, stratul rămas este filtrarea și nu rutarea.

Un firewall administrat de client poate bloca subrețeaua biroului cu un tabel de rutare perfect. Acea politică aparține celui care a distribuit profilul, nu persoanei care editează rute.