Cum verificați starea IPv6 a unui Mac după ce VPN-ul se deconectează
După o deconectare VPN, verificați adresa IPv6, ruta către destinația care eșuează și politica de blocare a clientului în această ordine, înainte de orice resetare.
Ajungeți la un site prin IPv4 după ce tunelul cade și nu ați dovedit nimic despre IPv6. macOS configurează cele două familii separat, pentru fiecare serviciu de rețea, iar un client VPN poate schimba una fără să o atingă pe cealaltă. Parcurgeți cele trei straturi în ordine: configurarea adresei, selecția rutei și apoi orice politică instalată de client cât timp este deconectat. Între timp, păstrați neschimbată rețeaua de acces, altfel veți compara două probleme diferite.
Începeți cu familia care chiar s-a stricat
O pagină care se încarcă prin IPv4 vă spune că rețeaua fizică este vie. Nu spune nimic despre dacă serviciul are o adresă IPv6 globală, dacă prefixul este încă anunțat sau dacă ceva filtrează familia. Confirmați ce a eșuat înainte de a alege un instrument, pentru că un nume care se rezolvă la o adresă inaccesibilă arată identic cu un nume care nu se rezolvă deloc. Întrebați ce strat a răspuns greșit și scrieți răspunsul. Fără asta, fiecare pas ulterior este o presupunere îmbrăcată în procedură.
Păstrați aceeași rețea Wi-Fi și același punct de acces pe toată durata comparației. O rețea de cafenea care ieri oferea IPv6 nu spune nimic despre cea pe care sunteți acum.
Citiți adresa înainte de rută
În Setările Sistemului, panoul TCP/IP al serviciului activ arată dacă IPv6 este automat, manual sau doar local de legătură. Comparați asta cu ce așteptați, ținând cont că o organizație poate fi ales configurarea manuală în mod deliberat. Apoi rulați ifconfig și citiți interfața respectivă. O adresă fe80:: singură înseamnă că interfața poate vorbi cu vecinii ei și nimic mai mult, deci prezența locală de legătură nu este dovada unei căi utilizabile.
Căutați și interfețe utun lăsate de client. Un dispozitiv de tunel vechi poate păstra o adresă și o rută mult după ce clientul a încetat să îl folosească. Dacă există unul, este o constatare de ciclu de viață pentru proprietarul clientului, nu ceva de șters pe loc.
Citiți tabelul de rute pentru destinația care eșuează
Întrebați nucleul despre destinația care a eșuat, nu despre ruta implicită. route -n get 2001:db8::25 afișează interfața și gateway-ul alese pentru acea adresă, iar netstat -rn -f inet6 arată întregul tabel pentru comparație. O rută implicită vă spune că există o implicită; nu vă spune că această destinație o folosește.
Țineți DNS în compartimentul lui. Un resolver accesibil prin IPv4 poate returna în continuare înregistrări AAAA, așa că o eroare de căutare și o eroare de rutare produc același simptom în browser.
Separați politica de blocare a clientului de o rămășiță
Unii clienți sunt proiectați să blocheze traficul cât timp sunt deconectați, inclusiv cealaltă familie de adrese, iar acest comportament este o funcție, nu un defect.
Aflați ce comportament documentează clientul dumneavoastră înainte de a trata o blocare ca daună. scutil --dns arată resolverele în vigoare pe serviciu, și acolo devine vizibil un resolver instalat de client sau o setare DNS cu domeniu de aplicare. Apoi verificați dacă au fost instalate și lăsate în urmă reguli de filtrare a pachetelor. O blocare așteptată și o regulă rămasă necesită răspunsuri opuse, iar doar documentația proprietarului le separă.
Adunați dovezi, apoi schimbați un singur lucru
Notați versiunea clientului, versiunea macOS, serviciul de rețea, politica deconectată preconizată și ieșirea adreselor și rutelor de ambele părți ale unui ciclu de conectare și deconectare. Acea înregistrare este cea care transformă o plângere într-o problemă de ciclu de viață pe care cineva o poate investiga. Apoi faceți o singură modificare și măsurați din nou.
Rezistați resetării. Ștergerea interfețelor virtuale, golirea tabelului de rute și dezactivarea IPv6 pe tot computerul distrug starea pe care trebuia să o capturați și pot lua cu ele configurație nelegată. Dacă clientul are un flux acceptat de pauză, reparare sau dezinstalare, folosiți-l și urmați procedura administratorului acolo unde rețeaua este administrată. Un computer care a fost deja resetat nu îi dă proprietarului nimic cu care să lucreze și de obicei reproduce defectul la următoarea conexiune.