Sådan kontrollerer du en Macs IPv6-tilstand, efter VPN'en afbrydes

Nå et websted over IPv4, efter at tunnelen er faldet, og du har ikke bevist noget om IPv6. macOS konfigurerer de to familier separat, pr. netværkstjeneste, og en VPN-klient kan ændre den ene uden at røre den anden. Gå gennem de tre lag i rækkefølge: adressekonfiguration, rutevalg og derefter den politik, klienten installerer, mens den er afbrudt. Hold adgangsnetværket uændret imens, ellers sammenligner du to forskellige problemer.

Begynd med den familie, der faktisk gik i stykker

En side, der indlæses over IPv4, fortæller dig, at det fysiske netværk er levende. Den siger intet om, hvorvidt tjenesten har en global IPv6-adresse, om præfikset stadig annonceres, eller om noget filtrerer familien. Bekræft, hvad der fejlede, før du vælger et værktøj, for et navn, der opløses til en uopnåelig adresse, ser identisk ud med et navn, der slet ikke opløses. Spørg, hvilket lag der svarede forkert, og skriv svaret ned. Uden det er hvert senere skridt gætværk klædt ud som procedure.

Behold det samme Wi-Fi-netværk og adgangspunkt gennem hele sammenligningen. Et cafenetværk, der tilbød IPv6 i går, siger intet om det, du er på nu.

Læs adressen før ruten

I Systemindstillinger viser den aktive tjenestes TCP/IP-panel, om IPv6 er automatisk, manuel eller kun link-local. Sammenlign det med det, du forventer, og husk, at en organisation kan have valgt manuel konfiguration med vilje. Kør derefter ifconfig og læs det pågældende interface. En fe80::-adresse alene betyder, at interfacet kan tale med sine naboer og intet mere, så tilstedeværelsen af en link-local adresse er ikke bevis på en brugbar vej.

Se også efter utun-interfaces, som klienten har efterladt. En forældet tunnel-enhed kan holde en adresse og en rute længe efter, at klienten er holdt op med at bruge den. Hvis der er en, er det et livscyklusfund for klientens ejer og ikke noget, der skal slettes med det samme.

Læs rutetabellen for den fejlende destination

Spørg kernen om den destination, der fejlede, ikke om standardruten. route -n get 2001:db8::25 udskriver det interface og den gateway, der er valgt for den adresse, og netstat -rn -f inet6 viser hele tabellen til sammenligning. En standardrute fortæller dig, at en standard findes; den fortæller ikke, at denne destination bruger den.

Hold DNS i sit eget rum. En resolver, der kan nås over IPv4, kan stadig returnere AAAA-poster, så en opslagsfejl og en routingfejl giver det samme symptom i browseren.

Adskil klientens blokeringspolitik fra en rest

Nogle klienter er designet til at blokere trafik, mens de er afbrudt, inklusive den anden adressefamilie, og den adfærd er en funktion, ikke en fejl.

Find ud af, hvilken adfærd din klient dokumenterer, før du behandler en blokering som skade. scutil --dns viser de resolvere, der gælder pr. tjeneste, og det er der, en klientinstalleret resolver eller en afgrænset DNS-indstilling bliver synlig. Kontroller derefter, om pakkefilterregler blev installeret og efterladt. En forventet blokering og en restregel kræver modsatte reaktioner, og kun ejerens dokumentation skelner dem.

Indsaml beviser, skift derefter én ting

Registrer klientversionen, macOS-versionen, netværkstjenesten, den tilsigtede afbrudte politik og adresse- og ruteoutputtet på begge sider af én forbind-afbryd-cyklus. Det er den registrering, der gør en klage til et livscyklusproblem, som nogen kan undersøge. Foretag derefter en enkelt ændring og mål igen.

Modstå nulstillingen. Sletning af virtuelle interfaces, tømning af rutetabellen og deaktivering af IPv6 på hele maskinen ødelægger alle den tilstand, du havde brug for at fange, og de kan tage urelateret konfiguration med sig. Hvis klienten har et understøttet forløb til pause, reparation eller afinstallation, så brug det, og følg administratorens procedure, hvor netværket er administreret. En maskine, der allerede er nulstillet, giver ejeren intet at arbejde med, og den genskaber som regel fejlen ved næste forbindelse.