Kaip patikrinti „Mac“ IPv6 būseną atsijungus VPN

Jei po tunelio kritimo pasieksite svetainę per IPv4, apie IPv6 dar nieko neįrodėte. macOS dvi šeimas konfigūruoja atskirai, kiekvienai tinklo paslaugai, o VPN klientas gali pakeisti vieną neliesdamas kitos. Peržiūrėkite tris sluoksnius iš eilės: adreso konfigūraciją, maršruto pasirinkimą ir tada bet kokią politiką, kurią klientas įdiegia atsijungęs. Tuo metu palikite prieigos tinklą nepakeistą, kitaip lyginsite dvi skirtingas problemas.

Pradėkite nuo šeimos, kuri tikrai sugedo

Puslapis, įkeliamas per IPv4, pasako, kad fizinis tinklas gyvas. Jis nieko nesako apie tai, ar paslauga turi visuotinį IPv6 adresą, ar priešdėlis vis dar skelbiamas, ar kažkas filtruoja šeimą. Patvirtinkite, kas nepavyko, prieš rinkdamiesi įrankį, nes vardas, kuris išsprendžiamas į nepasiekiamą adresą, atrodo lygiai taip pat kaip vardas, kuris visai neišsprendžiamas. Paklauskite, kuris sluoksnis atsakė neteisingai, ir užsirašykite atsakymą. Be to kiekvienas vėlesnis žingsnis yra spėjimas procedūros drabužiais.

Viso palyginimo metu naudokite tą patį Wi-Fi tinklą ir tą patį prieigos tašką. Kavinės tinklas, kuris vakar siūlė IPv6, nieko nesako apie tą, kuriame esate dabar.

Skaitykite adresą prieš maršrutą

Sistemos nuostatose aktyvios paslaugos TCP/IP skydelis rodo, ar IPv6 automatinis, rankinis, ar tik vietinis. Palyginkite tai su tuo, ko tikitės, prisimindami, kad organizacija galėjo sąmoningai pasirinkti rankinę konfigūraciją. Tada paleiskite ifconfig ir perskaitykite atitinkamą sąsają. Vien tik fe80:: adresas reiškia, kad sąsaja gali kalbėtis su kaimynais ir nieko daugiau, todėl vietinio adreso buvimas nėra naudojamo kelio įrodymas.

Taip pat ieškokite utun sąsajų, kurias klientas paliko. Pasenęs tunelio įrenginys gali ilgai išlaikyti adresą ir maršrutą po to, kai klientas nustojo jį naudoti. Jei tokia yra, tai yra gyvavimo ciklo radinys kliento savininkui, o ne kažkas, ką reikia ištrinti vietoje.

Skaitykite maršrutų lentelę nepavykusiai paskirties vietai

Klauskite branduolio apie paskirties vietą, kuri nepavyko, o ne apie numatytąjį maršrutą. route -n get 2001:db8::25 išspausdina sąsają ir šliuzą, parinktus tam adresui, o netstat -rn -f inet6 rodo visą lentelę palyginimui. Numatytasis maršrutas pasako, kad numatytasis egzistuoja; jis nepasako, kad ši paskirties vieta jį naudoja.

Laikykite DNS atskirame skyriuje. Per IPv4 pasiekiamas sprendėjas vis tiek gali grąžinti AAAA įrašus, todėl paieškos klaida ir maršrutizavimo klaida naršyklėje sukelia tą patį simptomą.

Atskirkite kliento blokavimo politiką nuo likučio

Kai kurie klientai sukurti blokuoti srautą, kol jie atjungti, įskaitant kitą adresų šeimą, ir šis elgesys yra funkcija, o ne defektas.

Išsiaiškinkite, kokį elgesį dokumentuoja jūsų klientas, prieš traktuodami blokavimą kaip žalą. scutil --dns rodo paslaugai galiojančius sprendėjus, ir būtent ten tampa matomas kliento įdiegtas sprendėjas arba apribotas DNS nustatymas. Tada patikrinkite, ar buvo įdiegtos ir paliktos paketų filtro taisyklės. Tikėtinas blokavimas ir likusi taisyklė reikalauja priešingų reakcijų, ir tik savininko dokumentacija jas atskiria.

Surinkite įrodymus, tada pakeiskite vieną dalyką

Užrašykite kliento versiją, macOS versiją, tinklo paslaugą, numatytą atjungimo politiką ir adresų bei maršrutų išvestį abiejose vieno prisijungimo ir atsijungimo ciklo pusėse. Šis įrašas paverčia skundą gyvavimo ciklo problema, kurią kas nors gali ištirti. Tada atlikite vieną pakeitimą ir vėl išmatuokite.

Priešinkitės atkūrimui. Virtualių sąsajų trynimas, maršrutų lentelės išvalymas ir IPv6 išjungimas visame kompiuteryje naikina būseną, kurią reikėjo užfiksuoti, ir gali kartu pasiimti nesusijusią konfigūraciją. Jei klientas turi palaikomą pauzės, taisymo ar šalinimo eigą, naudokite ją ir laikykitės administratoriaus procedūros ten, kur tinklas valdomas. Jau atkurtas kompiuteris savininkui nieko neduoda, ir paprastai pakartoja gedimą kitą kartą prisijungus.