Jak zkontrolovat stav IPv6 na Macu po odpojení VPN

Dostaňte se na web přes IPv4 poté, co tunel spadne, a o IPv6 jste nedokázali nic. macOS konfiguruje obě rodiny odděleně, pro každou síťovou službu, a klient VPN může změnit jednu, aniž by se dotkl druhé. Projděte tři vrstvy v pořadí: konfigurace adresy, volba trasy a poté jakákoli politika, kterou klient nainstaluje, dokud je odpojený. Přístupovou síť mezitím nechte beze změny, jinak budete porovnávat dva různé problémy.

Začněte rodinou, která se skutečně rozbila

Stránka, která se načte přes IPv4, vám říká, že fyzická síť žije. Neříká nic o tom, zda má služba globální adresu IPv6, zda se prefix stále inzeruje nebo zda něco rodinu filtruje. Potvrďte, co selhalo, než zvolíte nástroj, protože jméno, které se přeloží na nedostupnou adresu, vypadá stejně jako jméno, které se nepřeloží vůbec. Zeptejte se, která vrstva odpověděla špatně, a odpověď si zapište. Bez toho je každý další krok dohad oblečený do postupu.

Ponechte stejnou síť Wi-Fi a přístupový bod po celé srovnání. Síť v kavárně, která včera nabízela IPv6, neříká nic o té, na které jste teď.

Přečtěte adresu dřív než trasu

V Nastavení systému panel TCP/IP aktivní služby ukazuje, zda je IPv6 automatická, ruční nebo jen lokální pro spojení. Porovnejte to s tím, co očekáváte, a pamatujte, že organizace mohla ruční konfiguraci zvolit záměrně. Potom spusťte ifconfig a přečtěte dotyčné rozhraní. Samotná adresa fe80:: znamená, že rozhraní umí mluvit se svými sousedy a nic víc, takže přítomnost lokální adresy není důkazem použitelné cesty.

Hledejte také rozhraní utun, která klient zanechal. Zastaralé tunelové zařízení může držet adresu a trasu dlouho poté, co je klient přestal používat. Pokud tam nějaké je, je to zjištění životního cyklu pro vlastníka klienta, ne něco, co se má hned smazat.

Přečtěte směrovací tabulku pro nefunkční cíl

Zeptejte se jádra na cíl, který selhal, ne na výchozí trasu. route -n get 2001:db8::25 vypíše rozhraní a bránu zvolené pro tuto adresu a netstat -rn -f inet6 ukáže celou tabulku pro srovnání. Výchozí trasa vám říká, že výchozí existuje; neříká, že tento cíl ji používá.

Držte DNS ve vlastním oddílu. Rezolver dostupný přes IPv4 může stále vracet záznamy AAAA, takže selhání vyhledání a selhání směrování dávají v prohlížeči stejný příznak.

Oddělte blokovací politiku klienta od zbytku

Někteří klienti jsou navrženi tak, aby blokovali provoz, dokud jsou odpojení, včetně druhé rodiny adres, a toto chování je vlastnost, ne závada.

Zjistěte, jaké chování váš klient dokumentuje, než blokování začnete považovat za poškození. scutil --dns ukazuje rezolvery platné pro jednotlivé služby, a právě tam je vidět rezolver nainstalovaný klientem nebo omezené nastavení DNS. Potom zkontrolujte, zda byla nainstalována a zanechána pravidla filtru paketů. Očekávané blokování a zbylé pravidlo vyžadují opačné reakce a rozezná je jen dokumentace vlastníka.

Zachyťte důkazy, pak změňte jednu věc

Zapište verzi klienta, verzi macOS, síťovou službu, zamýšlenou politiku při odpojení a výstup adres a tras na obou stranách jednoho cyklu připojení a odpojení. Právě tento záznam mění stížnost v problém životního cyklu, který může někdo prošetřit. Potom proveďte jedinou změnu a změřte to znovu.

Odolejte resetu. Mazání virtuálních rozhraní, vyčištění směrovací tabulky a vypnutí IPv6 na celém stroji ničí stav, který jste potřebovali zachytit, a mohou s sebou vzít nesouvisející konfiguraci. Má-li klient podporovaný postup pro pozastavení, opravu nebo odinstalaci, použijte ho a řiďte se postupem správce tam, kde je síť spravovaná. Stroj, který už byl resetován, nedává vlastníkovi nic, s čím by mohl pracovat, a obvykle závadu při dalším připojení zopakuje.