Kiel kontroli la IPv6-staton de Mac post kiam la VPN malkonektiĝas

Vi atingas retejon per IPv4 post kiam la tunelo falis, kaj vi pruvis nenion pri IPv6. macOS agordas la du familiojn aparte, laŭ reta servo, kaj VPN-kliento povas ŝanĝi unu sen tuŝi la alian. Trairu la tri tavolojn en ordo: adresa agordo, itinera elekto, kaj poste ajna politiko, kiun la kliento instalas dum malkonektite. Konservu la alirreton senŝanĝa dume, alie vi komparos du malsamajn problemojn.

Komencu per la familio, kiu efektive rompiĝis

Paĝo, kiu ŝarĝiĝas per IPv4, diras al vi, ke la fizika reto vivas. Ĝi diras nenion pri tio, ĉu la servo havas tutmondan IPv6-adreson, ĉu la prefikso ankoraŭ estas anoncata, aŭ ĉu io filtras la familion. Konfirmu, kio malsukcesis, antaŭ ol elekti ilon, ĉar nomo, kiu solviĝas al neatingebla adreso, aspektas idente al nomo, kiu tute ne solviĝas. Demandu, kiu tavolo respondis malĝuste, kaj skribu la respondon. Sen tio, ĉiu posta paŝo estas konjekto vestita kiel proceduro.

Konservu la saman Wi-Fi-reton kaj alirpunkton dum la tuta komparo. Kafeja reto, kiu hieraŭ proponis IPv6, diras nenion pri tiu, sur kiu vi nun estas.

Legu la adreson antaŭ la itinero

En Sistemaj Agordoj, la langeto TCP/IP de la aktiva servo montras, ĉu IPv6 estas aŭtomata, mana aŭ nur loka-ligila. Komparu tion kun tio, kion vi atendas, memorante, ke organizo eble intence elektis manan agordon. Poste rulu ifconfig kaj legu la koncernan interfacon. Adreso fe80:: sola signifas, ke la interfaco povas paroli kun siaj najbaroj kaj nenion pli, do loka-ligila ĉeesto ne estas pruvo de uzebla vojo.

Serĉu ankaŭ interfacojn utun, kiujn la kliento postlasis. Malnova tunela aparato povas teni adreson kaj itineron longe post kiam la kliento ĉesis uzi ĝin. Se unu ĉeestas, tio estas vivcikla trovo por la posedanto de la kliento, ne io por tuj forigi.

Legu la itineran tabelon por la malsukcesa celo

Demandu la kernon pri la celo, kiu malsukcesis, ne pri la defaŭlta itinero. route -n get 2001:db8::25 presas la interfacon kaj enirejon elektitajn por tiu adreso, kaj netstat -rn -f inet6 montras la tutan tabelon por komparo. Defaŭlta itinero diras al vi, ke defaŭlto ekzistas; ĝi ne diras, ke ĉi tiu celo uzas ĝin.

Tenu DNS en sia propra fako. Solvilo atingebla per IPv4 ankoraŭ povas redoni rikordojn AAAA, do serĉa fiasko kaj itinera fiasko produktas la saman simptomon en la retumilo.

Apartigu la blokpolitikon de la kliento disde restaĵo

Iuj klientoj estas desegnitaj por bloki trafikon dum malkonektite, inkluzive de la alia adresfamilio, kaj tiu konduto estas trajto, ne difekto.

Elfindigu, kiun konduton via kliento dokumentas, antaŭ ol trakti blokon kiel damaĝon. scutil --dns montras la solvilojn validajn laŭ servo, kaj ĝuste tie videblas de la kliento instalita solvilo aŭ ampleksa DNS-agordo. Poste kontrolu, ĉu pakaĵfiltrilaj reguloj estis instalitaj kaj postlasitaj. Atendata bloko kaj restinta regulo postulas kontraŭajn respondojn, kaj nur la dokumentaro de la posedanto apartigas ilin.

Kolektu pruvojn, poste ŝanĝu unu aferon

Notu la klientan version, la macOS-version, la retan servon, la intencitan malkonektan politikon, kaj la adresan kaj itineran eligon ambaŭflanke de unu konekta-malkonekta ciklo. Tiu noto transformas plendon en vivciklan problemon, kiun iu povas esplori. Poste faru unu solan ŝanĝon kaj mezuru denove.

Rezistu la restarigon. Forigi virtualajn interfacojn, malplenigi la itineran tabelon kaj malŝalti IPv6 sur la tuta maŝino detruas la staton, kiun vi bezonis kapti, kaj ili povas forpreni nerilatan agordon. Se la kliento havas subtenatan paŭzan, riparan aŭ malinstalan fluon, uzu ĝin, kaj sekvu la proceduron de la administranto tie, kie la reto estas administrata. Maŝino, kiu jam estis restarigita, donas al la posedanto nenion por labori, kaj ĝi kutime reproduktas la difekton ĉe la sekva konekto.