Macin IPv6-tilan tarkistaminen VPN-yhteyden katkeamisen jälkeen

Saavutat sivuston IPv4:n kautta tunnelin pudottua, etkä ole todistanut IPv6:sta mitään. macOS määrittää kaksi perhettä erikseen, verkkopalveluittain, ja VPN-asiakas voi muuttaa toista koskematta toiseen. Käy kolme kerrosta läpi järjestyksessä: osoitteen määritys, reitin valinta ja sitten mikä tahansa käytäntö, jonka asiakas asentaa katkaistuna ollessaan. Pidä käyttöverkon tila muuttumattomana sillä välin, tai vertailet kahta eri ongelmaa.

Aloita perheestä, joka todella hajosi

IPv4:n kautta latautuva sivu kertoo, että fyysinen verkko on elossa. Se ei kerro, onko palvelulla globaalia IPv6-osoitetta, mainostetaanko etuliitettä yhä vai suodattaako jokin perhettä. Vahvista, mikä epäonnistui, ennen kuin valitset työkalun, sillä nimi, joka ratkeaa tavoittamattomaksi osoitteeksi, näyttää täsmälleen samalta kuin nimi, joka ei ratkea lainkaan. Kysy, mikä kerros vastasi väärin, ja kirjoita vastaus muistiin. Ilman sitä jokainen myöhempi vaihe on proseduuriksi puettu arvaus.

Pidä sama Wi-Fi-verkko ja tukiasema koko vertailun ajan. Eilen IPv6:ta tarjonnut kahvilaverkko ei kerro mitään siitä, jossa olet nyt.

Lue osoite ennen reittiä

Järjestelmäasetuksissa aktiivisen palvelun TCP/IP-paneeli näyttää, onko IPv6 automaattinen, manuaalinen vai vain linkkipaikallinen. Vertaa sitä siihen, mitä odotat, ja muista, että organisaatio on voinut valita manuaalisen määrityksen tarkoituksella. Aja sitten ifconfig ja lue kyseinen liitäntä. Yksinään fe80::-osoite tarkoittaa, että liitäntä voi puhua naapuriensa kanssa eikä muuta, joten linkkipaikallinen läsnäolo ei ole todiste käyttökelpoisesta reitistä.

Etsi myös utun-liitäntöjä, jotka asiakas on jättänyt jälkeensä. Vanhentunut tunnelilaite voi pitää osoitetta ja reittiä kauan sen jälkeen, kun asiakas lopetti sen käytön. Jos sellainen on, se on elinkaarilöydös asiakkaan omistajalle, ei mitään heti poistettavaa.

Lue reittitaulu epäonnistuvalle kohteelle

Kysy ytimeltä epäonnistuneesta kohteesta, älä oletusreitistä. route -n get 2001:db8::25 tulostaa kyseiselle osoitteelle valitun liitännän ja yhdyskäytävän, ja netstat -rn -f inet6 näyttää koko taulun vertailua varten. Oletusreitti kertoo, että oletus on olemassa; se ei kerro, että tämä kohde käyttää sitä.

Pidä DNS omassa lokerossaan. IPv4:n kautta tavoitettavissa oleva ratkaisija voi silti palauttaa AAAA-tietueita, joten haku epäonnistuu ja reititys epäonnistuu samalla oireella selaimessa.

Erottele asiakkaan estokäytäntö jäänteestä

Jotkin asiakkaat on suunniteltu estämään liikennettä, kun ne ovat katkaistuina, mukaan lukien toinen osoiteperhe, ja tämä käytös on ominaisuus, ei vika.

Ota selvää, mitä käytöstä asiakkaasi dokumentoi, ennen kuin kohtelet estoa vauriona. scutil --dns näyttää palvelukohtaisesti voimassa olevat ratkaisijat, ja juuri siellä asiakkaan asentama ratkaisija tai rajattu DNS-asetus tulee näkyviin. Tarkista sitten, asennettiinko pakettisuodattimen sääntöjä ja jätettiinkö ne. Odotettu esto ja jäljelle jäänyt sääntö vaativat vastakkaisia reaktioita, ja vain omistajan dokumentaatio erottaa ne.

Kerää todisteet ja muuta sitten yhtä asiaa

Kirjaa asiakasversio, macOS-versio, verkkopalvelu, aiottu katkaistun tilan käytäntö sekä osoite- ja reittituloste yhden yhdistä-katkaise-syklin molemmilta puolilta. Juuri tämä kirjaus muuttaa valituksen elinkaariongelmaksi, jota joku voi tutkia. Tee sitten yksi ainoa muutos ja mittaa uudelleen.

Vastusta nollausta. Virtuaaliliitäntöjen poistaminen, reittitaulun tyhjentäminen ja IPv6:n poistaminen käytöstä koko koneessa tuhoavat sen tilan, joka sinun piti tallentaa, ja ne voivat viedä mukanaan asiaankuulumatonta määritystä. Jos asiakkaalla on tuettu keskeytys-, korjaus- tai poistoprosessi, käytä sitä ja noudata ylläpitäjän menettelyä siellä, missä verkkoa hallitaan. Kone, joka on jo nollattu, ei anna omistajalle mitään työkalua, ja se yleensä toistaa vian seuraavalla yhteydellä.