De ce o rută VPN largă strică câteva site-uri publice

Majoritatea paginilor se încarcă, două sau trei expirează, iar browserul dă vina pe conexiune. Site-urile care eșuează au ceva în comun ce cele care funcționează nu au: adresele lor rezolvate cad în interiorul unui prefix instalat de VPN. O rută suficient de largă pentru a acoperi un interval public va captura trafic pe care tunelul nu trebuia să-l transporte niciodată, iar simptomul arată ca o problemă a site-ului, nu ca o decizie de rutare.

Rezolvați numele care eșuează, apoi priviți tabelul de rutare, nu browserul.

Comparați adresa, nu numele site-ului

Căutați adresa pe care clientul a încercat-o de fapt, apoi verificați ce rută corespunde acesteia. O destinație din interiorul 45.61.20.10 intră sub 45.0.0.0/8 dacă acel prefix este prezent, chiar dacă site-ul în sine nu are nimic de-a face cu tunelul. Compararea adresei care eșuează cu prefixele instalate este o problemă de scădere, nu o presupunere.

Windows poate răspunde direct la ambele jumătăți, iar o căutare arată ce interfață și ce următor salt au câștigat selecția. Rezolvați numele de două ori dacă site-ul returnează mai multe adrese. Notați fiecare cu ruta care s-a potrivit. Adrese diferite pot da răspunsuri diferite, iar doar una dintre ele poate fi cazul care eșuează.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Citiți prefixul potrivit cel mai specific, nu prima linie care pare familiară. O rută prezentă în tabel nu dovedește că a câștigat căutarea; cea mai lungă potrivire o face. Două prefixe pot corespunde unei adrese, iar doar unul primește pachetul. Învinsul rămâne în tabel și arată la fel de real într-o listare.

Notați prefixul, interfața acestuia și adresa rezolvată. Aceste trei valori sunt întregul diagnostic.

Aflați cine a instalat ruta

Rutele vin din patru locuri: profilul VPN nativ, o politică de administrare, un script de conectare sau un client complet diferit. Ștergerea intrării active poate confirma relevanța ei, dar următoarea conectare o recreează din configurația salvată, deci sursa este ce trebuie schimbat.

Verificați mai întâi lista de rute a profilului, apoi politica de administrare, apoi orice script care rulează la conectare. Această ordine corespunde frecvenței cu care fiecare se dovedește responsabil. Ea menține și schimbarea într-un singur strat, nu în trei.

Citiți cu atenție comportamentul nativ bazat pe clase

Profilurile native Windows au o setare documentată, NativeProfile/DisableClassBasedDefaultRoute, care controlează o rută automată dedusă din adresa interfeței. O adresă de profil care începe cu 45 poate produce o intrare 45.0.0.0/8 în cadrul acelui comportament, și astfel o singură adresă publică capturează un întreg interval de clasă A.

Numele proprietății invită la o citire greșită: setarea pe true dezactivează deducerea, iar false o activează. Nu este nici același obiect ca o rută implicită și nu guvernează clienții terți care își instalează propriile prefixe.

Dacă deducerea este cauza dovedită, corectați profilul prin proprietarul său de administrare și furnizați explicit prefixele private prevăzute. Dacă un script a adăugat intrarea, reparați scriptul. Înlocuirea unei rute largi neexplicate cu alta schimbă simptomul fără a răspunde la întrebare.

Reparați sursa, apoi verificați din nou ambele căi

După schimbare, reconectați-vă și repetați căutarea pentru un site public care eșuează și pentru o resursă care trebuie să folosească tunelul. Prima ar trebui să se rezolve acum la interfața fizică, iar a doua ar trebui să selecteze în continuare VPN-ul. Nu vă opriți la primul succes; o corecție care strică și accesul privat a schimbat o defecțiune cu alta.

Examinați în același timp planul de adrese al serverului. Un pool care se suprapune cu spațiul public provoacă acest tip de problemă iar și iar. Un interval ales intenționat de operator merită o altă conversație, nu o renumerotare automată.

Creșterea MTU sau golirea DNS nu vor corecta un prefix care încă direcționează acea adresă în tunel. Testați mai întâi selecția, apoi calea.