Korleis kontrollere IPv6-tilstanden til ein Mac etter at VPN-en koplar frå

Når du når eit nettstad over IPv4 etter at tunnelen har falle, har du ikkje prova noko om IPv6. macOS konfigurerer dei to familiane kvar for seg, per nettverksteneste, og ein VPN-klient kan endre den eine utan å røre den andre. Gå gjennom dei tre laga i rekkjefølgje: adressekonfigurasjon, ruteval og deretter den policyen klienten installerer medan han er fråkopla. Hald tilgangsnettet uendra i mellomtida, elles samanliknar du to ulike problem.

Start med familien som faktisk gjekk i stykker

Ei side som lastar over IPv4 fortel deg at det fysiske nettet lever. Ho seier ingenting om tenesta har ei global IPv6-adresse, om prefikset framleis blir annonsert, eller om noko filtrerer familien. Stadfest kva som feila før du vel verktøy, for eit namn som blir løyst til ei utilgjengeleg adresse ser identisk ut med eit namn som ikkje blir løyst i det heile. Spør kva lag som svara feil, og skriv ned svaret. Utan det er kvart seinare steg gjetting kledd ut som prosedyre.

Hald det same Wi-Fi-nettet og same tilgangspunkt gjennom heile samanlikninga. Eit kafénett som tilbaud IPv6 i går, seier ingenting om det du er på no.

Les adressa før ruta

I Systeminnstillingar viser TCP/IP-panelet for den aktive tenesta om IPv6 er automatisk, manuell eller berre link-lokal. Samanlikn det med det du ventar, og hugs at ein organisasjon kan ha valt manuell konfigurasjon med vilje. Køyr deretter ifconfig og les grensesnittet det gjeld. Ei fe80::-adresse åleine tyder at grensesnittet kan snakke med grannane sine og ikkje noko meir, så link-lokal tilstadevære er ikkje prov på ein brukbar veg.

Sjå også etter utun-grensesnitt som klienten har etterlate. Ei forelda tunneleining kan halde på ei adresse og ei rute lenge etter at klienten slutta å bruke ho. Viss det finst eitt, er det eit livssyklusfunn for eigaren av klienten, ikkje noko som skal slettast på staden.

Les rutetabellen for destinasjonen som feilar

Spør kjernen om destinasjonen som feila, ikkje om standardruta. route -n get 2001:db8::25 skriv ut grensesnittet og gatewayen som er valde for den adressa, og netstat -rn -f inet6 viser heile tabellen for samanlikning. Ei standardrute fortel deg at ein standard finst; ho fortel ikkje at denne destinasjonen brukar han.

Hald DNS i eige rom. Ein resolver som er tilgjengeleg over IPv4, kan framleis returnere AAAA-oppføringar, så ein oppslagsfeil og ein rutefeil gir same symptom i nettlesaren.

Skil blokkeringspolicyen til klienten frå ein rest

Nokre klientar er laga for å blokkere trafikk medan dei er fråkopla, inkludert den andre adressefamilien, og den åtferda er ein funksjon, ikkje ein feil.

Finn ut kva åtferd klienten din dokumenterer før du behandlar ei blokkering som skade. scutil --dns viser resolverane som gjeld per teneste, og det er der ein klientinstallert resolver eller ei avgrensa DNS-innstilling blir synleg. Sjekk deretter om pakkefilterreglar vart installerte og etterlatne. Ei forventa blokkering og ein restregel krev motsette reaksjonar, og berre dokumentasjonen til eigaren skil dei.

Samle bevis, endre så éin ting

Registrer klientversjonen, macOS-versjonen, nettverkstenesta, den tiltenkte fråkopla policyen og adresse- og ruteutdata på begge sider av ein tilkopling-fråkobling-syklus. Det er den registreringa som gjer ei klage om til eit livssyklusproblem nokon kan undersøke. Gjer deretter éi einskild endring og mål på nytt.

Motstå nullstillinga. Sletting av virtuelle grensesnitt, tømming av rutetabellen og deaktivering av IPv6 på heile maskina øydelegg alle den tilstanden du trong å fange, og dei kan ta med seg urelatert konfigurasjon. Viss klienten har ein støtta flyt for pause, reparasjon eller avinstallering, bruk han, og følg prosedyren til administratoren der nettet er administrert. Ei maskin som alt er nullstilt, gir eigaren ingenting å jobbe med, og ho attskapar som regel feilen ved neste tilkopling.