Verificarea rutei VPN pe macOS: route get fără a schimba nimic

Un utilizator ajunge la intranet în rețeaua biroului și nu prin tunel, în timp ce Setările arată în continuare VPN-ul ca fiind conectat. Editarea tabelului de rute în acel moment riscă să întrerupă sesiunea de la distanță pe care o folosiți pentru diagnosticare. Întrebați în schimb nucleul ce cale ar alege pentru gazda care eșuează. Utilitarul route din macOS are o operație get care răspunde exact la asta, pentru o singură destinație, fără a schimba nimic.

Întrebați gazda care eșuează, nu ruta implicită

O captură a rutei implicite spune foarte puțin pe un Mac modern, pentru că o destinație mai specifică sau o politică limitată pot anula ceea ce ruta implicită pare să spună. Tunelul poate fi activ, ruta implicită poate părea corectă, iar singura gazdă de care aveți nevoie poate fi totuși rutată în altă parte. Interogați adresa care eșuează și lăsați nucleul să numească calea aleasă.

Forma este route -n get urmată de adresă: route -n get 203.0.113.10, unde adresa de documentație reprezintă ținta dvs. Folosiți destinația autorizată și familia de adrese corespunzătoare, pentru că un răspuns IPv4 nu spune nimic despre o resursă doar IPv6. Documentația utilitarului route descrie operația get și câmpurile pe care le afișează.

Citiți interfața și gateway-ul ca dovezi

Rulați interogarea înainte de a conecta VPN-ul și apoi din nou după, și comparați liniile de interfață și gateway. Diferența dintre cele două răspunsuri este ceea ce tunelul a schimbat de fapt, și este mult mai utilă decât o listare completă a tabelului. Dacă interfața este identică în ambele rulări, ruta nu a fost niciodată problema și puteți înceta să priviți rutarea.

Notați destinația, interfața, gateway-ul și momentul interogării înainte de a trage o concluzie. Ieșirea este dovadă, nu diagnostic: aceeași interfață poate fi corectă pentru o gazdă și greșită pentru alta când este implicat un tunel divizat.

O rută corectă nu este o cerere care funcționează

O rută vă spune ce interfață ar folosi nucleul, nimic mai mult. DNS, un firewall al gazdei și autorizarea aplicației stau toate deasupra acelei decizii, iar cererea poate eșua după ce rutarea reușește. Păstrați simptomul exact înainte de a continua, pentru că "nu se poate conecta" și "se conectează dar returnează o eroare" sunt investigații diferite cu pași următori diferiți. Vederea resolverului și vederea interfeței completează interogarea destinației în loc să o înlocuiască.

O listare a tabelului de rutare încă își are locul: așa observați o rută implicită neașteptată. O rută implicită obișnuită rămasă nu dovedește că VPN-ul nu este folosit, pentru că intrările mai specifice câștigă în fața ei.

Țineți punctul final și resursa separate

Sunt implicate două căutări și ele răspund la întrebări diferite. A ajunge la punctul final este o călătorie exterioară prin rețeaua fizică. A ajunge la aplicație se întâmplă în interiorul tunelului, la o adresă care există doar pe partea privată. Confundarea celor două produce clasica buclă falsă, în care punctul final pare rutat prin tunelul pe care îl încheie. Interogați ambele adrese separat, etichetați fiecare rezultat, iar confuzia dispare.

Suprapunerea prefixelor este celălalt caz care merită cunoscut. Când intervalele local și la distanță se suprapun, decide potrivirea celui mai lung prefix, așa că o subrețea locală suprapusă poate umbri adresa la distanță pe care o așteptați. Destinația privată arată atunci identic cu una locală, iar corecția aparține planului de adrese, nu tabelului de rute. Interogarea get arată ce interfață a câștigat, și acesta este faptul de care aveți nevoie înainte de a schimba ceva.

Citiți mai întâi, schimbați mai târziu

Țineți route add și route delete în afara primei treceri. Pe un Mac pe care îl administrați de la distanță, o singură editare neglijentă a tabelului poate lua exact calea înapoi la mașină și nu mai lasă pe nimeni să termine diagnosticul. Decideți care rută este corectă, notați cum se anulează schimbarea și abia apoi executați-o. Inspecția nu are o asemenea coadă.

Aceeași prudență se aplică pentru golirea cache-urilor și repornirea serviciilor de rețea ca prim pas, pentru că ambele distrug dovada pe care urma să o citiți. Verificările doar de citire sunt ieftine, repetabile și sigure în orice ordine. Faceți-le pasul implicit și recurgeți la o schimbare doar când dovada indică una.