Så kontrollerar du en Macs IPv6-läge efter att VPN:en kopplas från

Når du en webbplats över IPv4 efter att tunneln fallit har du inte bevisat något om IPv6. macOS konfigurerar de två familjerna var för sig, per nätverkstjänst, och en VPN-klient kan ändra den ena utan att röra den andra. Gå igenom de tre lagren i ordning: adresskonfiguration, vägval och sedan den policy klienten installerar medan den är frånkopplad. Håll åtkomstnätet oförändrat under tiden, annars jämför du två olika problem.

Börja med familjen som faktiskt gick sönder

En sida som laddas över IPv4 säger att det fysiska nätet lever. Den säger inget om huruvida tjänsten har en global IPv6-adress, om prefixet fortfarande annonseras eller om något filtrerar familjen. Bekräfta vad som misslyckades innan du väljer verktyg, för ett namn som löses upp till en onåbar adress ser identiskt ut med ett namn som inte löses upp alls. Fråga vilket lager som svarade fel och skriv ned svaret. Utan det är varje senare steg gissning klädd i procedur.

Behåll samma Wi-Fi-nät och samma åtkomstpunkt under hela jämförelsen. Ett kafénät som erbjöd IPv6 i går säger ingenting om det du är på nu.

Läs adressen före vägen

I Systeminställningar visar TCP/IP-panelen för den aktiva tjänsten om IPv6 är automatiskt, manuellt eller bara link-local. Jämför det med vad du förväntar dig, och kom ihåg att en organisation kan ha valt manuell konfiguration med avsikt. Kör sedan ifconfig och läs det aktuella gränssnittet. En fe80::-adress ensam betyder att gränssnittet kan tala med sina grannar och inget mer, så link-local närvaro är inte bevis på en användbar väg.

Leta också efter utun-gränssnitt som klienten lämnat kvar. En föråldrad tunnelenhet kan hålla en adress och en väg länge efter att klienten slutat använda den. Om en finns är det ett livscykelfynd för klientens ägare, inte något att radera på plats.

Läs routingtabellen för målet som misslyckas

Fråga kärnan om målet som misslyckades, inte om standardvägen. route -n get 2001:db8::25 skriver ut det gränssnitt och den gateway som valts för den adressen, och netstat -rn -f inet6 visar hela tabellen för jämförelse. En standardväg säger att en standard finns; den säger inte att det här målet använder den.

Håll DNS i sitt eget fack. En resolver som nås över IPv4 kan fortfarande returnera AAAA-poster, så ett uppslagsfel och ett routingfel ger samma symptom i webbläsaren.

Skilj klientens blockeringspolicy från en rest

Vissa klienter är utformade för att blockera trafik medan de är frånkopplade, inklusive den andra adressfamiljen, och det beteendet är en funktion, inte ett fel.

Ta reda på vilket beteende din klient dokumenterar innan du behandlar en blockering som skada. scutil --dns visar de resolvers som gäller per tjänst, och det är där en klientinstallerad resolver eller en avgränsad DNS-inställning blir synlig. Kontrollera sedan om paketfilterregler installerades och lämnades kvar. En förväntad blockering och en kvarvarande regel kräver motsatta reaktioner, och bara ägarens dokumentation skiljer dem åt.

Samla bevis och ändra sedan en sak

Registrera klientversionen, macOS-versionen, nätverkstjänsten, den avsedda policyn vid frånkoppling och adress- och vägutdata på båda sidor av en anslutnings-frånkopplingscykel. Det är den registreringen som gör ett klagomål till ett livscykelproblem som någon kan undersöka. Gör sedan en enda ändring och mät igen.

Motstå återställningen. Att radera virtuella gränssnitt, tömma routingtabellen och inaktivera IPv6 på hela maskinen förstör allt det tillstånd du behövde fånga, och de kan ta med sig orelaterad konfiguration. Om klienten har ett stött flöde för paus, reparation eller avinstallation, använd det, och följ administratörens procedur där nätet är hanterat. En maskin som redan återställts ger ägaren inget att arbeta med, och den återskapar oftast felet vid nästa anslutning.