Kuidas kontrollida Maci IPv6 olekut pärast VPN-i lahtiühendamist

Jõuate saidile IPv4 kaudu pärast tunneli kukkumist ja te ei ole IPv6 kohta midagi tõestanud. macOS seadistab kahte perekonda eraldi, võrguteenuse kaupa, ja VPN-klient saab muuta ühte ilma teist puutumata. Käige kolm kihti järjekorras läbi: aadressi seadistus, marsruudi valik ja siis mis tahes poliitika, mille klient lahtiühendatud olekus paigaldab. Hoidke juurdepääsuvõrk vahepeal muutumatuna, muidu võrdlete kahte erinevat probleemi.

Alustage perekonnast, mis tegelikult katki läks

Leht, mis laadib IPv4 kaudu, ütleb teile, et füüsiline võrk on elus. See ei ütle midagi selle kohta, kas teenusel on globaalne IPv6-aadress, kas prefiksit ikka veel kuulutatakse või kas miski perekonda filtreerib. Kinnitage, mis nurjus, enne kui tööriista valite, sest kättesaamatusse aadressi lahenev nimi näeb välja täpselt sama nagu nimi, mis ei lahene üldse. Küsige, milline kiht vastas valesti, ja kirjutage vastus üles. Ilma selleta on iga järgmine samm protseduuriks riietatud oletus.

Hoidke kogu võrdluse ajal sama Wi-Fi-võrku ja pääsupunkti. Eile IPv6 pakkunud kohvikuvõrk ei ütle midagi selle kohta, milles te praegu olete.

Lugege aadress enne marsruuti

Süsteemiseadetes näitab aktiivse teenuse TCP/IP-paneel, kas IPv6 on automaatne, käsitsi või ainult lokaalne. Võrrelge seda oma ootusega, pidades meeles, et organisatsioon võis käsitsi seadistuse teadlikult valida. Seejärel käivitage ifconfig ja lugege kõnealust liidest. Ainuüksi aadress fe80:: tähendab, et liides saab oma naabritega rääkida ja mitte midagi enamat, seega lokaalse aadressi olemasolu ei ole tõestus kasutatavast teest.

Otsige ka liideseid utun, mille klient maha jättis. Vananenud tunneliseade võib hoida aadressi ja marsruuti kaua pärast seda, kui klient selle kasutamise lõpetas. Kui mõni on olemas, on see kliendi omaniku jaoks elutsükli leid, mitte asi, mida kohe kustutada.

Lugege nurjunud sihtkoha marsruuditabelit

Küsige tuumalt nurjunud sihtkoha kohta, mitte vaikemarsruudi kohta. route -n get 2001:db8::25 prindib selle aadressi jaoks valitud liidese ja lüüsi ning netstat -rn -f inet6 näitab võrdlemiseks kogu tabelit. Vaikemarsruut ütleb teile, et vaikeväärtus on olemas; see ei ütle, et see sihtkoht seda kasutab.

Hoidke DNS eraldi lahtris. IPv4 kaudu kättesaadav resolver võib ikkagi tagastada kirjeid AAAA, seega otsingu ebaõnnestumine ja marsruutimise ebaõnnestumine tekitavad brauseris sama sümptomi.

Eraldage kliendi blokeerimispoliitika jäägist

Mõned kliendid on loodud liiklust blokeerima, kuni nad on lahti ühendatud, sealhulgas teine aadressiperekond, ja see käitumine on omadus, mitte viga.

Uurige välja, millist käitumist teie klient dokumenteerib, enne kui käsitlete blokeeringut kahjustusena. scutil --dns näitab teenuse kaupa kehtivaid resolvereid, ja just seal muutub nähtavaks kliendi paigaldatud resolver või piiratud ulatusega DNS-seade. Seejärel kontrollige, kas paketifiltri reeglid paigaldati ja maha jäeti. Oodatud blokeering ja allesjäänud reegel nõuavad vastupidiseid reaktsioone ning ainult omaniku dokumentatsioon eristab neid.

Koguge tõendeid, seejärel muutke ühte asja

Kirjutage üles kliendi versioon, macOS-i versioon, võrguteenus, kavandatud lahtiühendatud poliitika ning aadressi- ja marsruudiväljund ühe ühendamis-lahutamistsükli mõlemal küljel. Just see kirje muudab kaebuse elutsükli probleemiks, mida keegi saab uurida. Seejärel tehke üksainus muudatus ja mõõtke uuesti.

Vastu lähtestamisele. Virtuaalsete liideste kustutamine, marsruuditabeli tühjendamine ja IPv6 väljalülitamine kogu masinas hävitavad oleku, mida teil oli vaja jäädvustada, ja võivad kaasa võtta mitteseotud seadistuse. Kui kliendil on toetatud pausi-, parandus- või desinstallimisvoog, kasutage seda, ja järgige administraatori protseduuri seal, kus võrku hallatakse. Masin, mis on juba lähtestatud, ei anna omanikule midagi, millega töötada, ja tavaliselt taastoodab vea järgmisel ühendusel.