Kā pārbaudīt Mac IPv6 stāvokli pēc VPN atvienošanas
Pēc VPN atvienošanas pirms jebkādas atiestatīšanas pārbaudiet IPv6 adresi, maršrutu uz neizdevušos galamērķi un klienta bloķēšanas politiku šajā secībā.
Ja pēc tuneļa sabrukuma sasniedzat vietni caur IPv4, par IPv6 jūs vēl neko neesat pierādījis. macOS abas saimes konfigurē atsevišķi, katram tīkla pakalpojumam, un VPN klients var mainīt vienu, neaizskarot otru. Izstaigājiet trīs slāņus pēc kārtas: adreses konfigurāciju, maršruta izvēli un pēc tam jebkuru politiku, ko klients instalē atvienotā stāvoklī. Tikmēr atstājiet piekļuves tīklu nemainītu, citādi jūs salīdzināsiet divas dažādas problēmas.
Sāciet ar saimi, kas tiešām salūza
Lapa, kas ielādējas caur IPv4, jums saka, ka fiziskais tīkls ir dzīvs. Tā neko nepasaka par to, vai pakalpojumam ir globāla IPv6 adrese, vai prefikss vēl tiek izziņots, vai kaut kas filtrē saimi. Pirms instrumenta izvēles apstipriniet, kas neizdevās, jo vārds, kas atrisinās uz nesasniedzamu adresi, izskatās tieši tāpat kā vārds, kas nemaz neatrisinās. Pajautājiet, kurš slānis atbildēja nepareizi, un pierakstiet atbildi. Bez tā katrs nākamais solis ir procedūras drānās ietīts minējums.
Visā salīdzināšanas laikā saglabājiet to pašu Wi-Fi tīklu un to pašu piekļuves punktu. Kafejnīcas tīkls, kas vakar piedāvāja IPv6, neko nepasaka par to, kurā jūs tagad esat.
Lasiet adresi pirms maršruta
Sistēmas iestatījumos aktīvā pakalpojuma TCP/IP panelis rāda, vai IPv6 ir automātisks, manuāls vai tikai lokāls. Salīdziniet to ar to, ko gaidāt, atceroties, ka organizācija var būt apzināti izvēlējusies manuālu konfigurāciju. Pēc tam palaidiet ifconfig un nolasiet attiecīgo saskarni. Viena pati fe80:: adrese nozīmē, ka saskarne var runāt ar kaimiņiem un neko vairāk, tāpēc lokālas adreses klātbūtne nav lietojama ceļa pierādījums.
Meklējiet arī utun saskarnes, ko klients atstājis. Novecojusi tuneļa ierīce var ilgi turēt adresi un maršrutu pēc tam, kad klients to pārstāja lietot. Ja tāda ir, tas ir dzīves cikla atradums klienta īpašniekam, nevis kaut kas tūlīt dzēšams.
Lasiet maršrutu tabulu neizdevušajam galamērķim
Jautājiet kodolam par galamērķi, kas neizdevās, nevis par noklusējuma maršrutu. route -n get 2001:db8::25 izdrukā saskarni un vārteju, kas izvēlētas šai adresei, un netstat -rn -f inet6 parāda visu tabulu salīdzināšanai. Noklusējuma maršruts pasaka, ka noklusējums eksistē; tas nepasaka, ka šis galamērķis to izmanto.
Turiet DNS savā nodalījumā. Caur IPv4 sasniedzams atrisinātājs joprojām var atgriezt AAAA ierakstus, tāpēc meklēšanas kļūda un maršrutēšanas kļūda pārlūkā rada vienu un to pašu simptomu.
Atdaliet klienta bloķēšanas politiku no atlikuma
Daži klienti ir veidoti tā, lai bloķētu satiksmi, kamēr tie ir atvienoti, tostarp otru adrešu saimi, un šī uzvedība ir funkcija, nevis defekts.
Noskaidrojiet, kādu uzvedību jūsu klients dokumentē, pirms uzskatāt bloķēšanu par bojājumu. scutil --dns parāda pakalpojumam spēkā esošos atrisinātājus, un tieši tur kļūst redzams klienta instalēts atrisinātājs vai ierobežots DNS iestatījums. Pēc tam pārbaudiet, vai paketes filtra noteikumi tika instalēti un atstāti. Gaidīta bloķēšana un atlikušais noteikums prasa pretējas reakcijas, un tos šķir tikai īpašnieka dokumentācija.
Savāciet pierādījumus, pēc tam mainiet vienu lietu
Pierakstiet klienta versiju, macOS versiju, tīkla pakalpojumu, paredzēto atvienotā stāvokļa politiku un adrešu un maršrutu izvadi abās viena savienošanas un atvienošanas cikla pusēs. Šis ieraksts pārvērš sūdzību dzīves cikla problēmā, ko kāds var izmeklēt. Pēc tam veiciet vienu izmaiņu un mēriet vēlreiz.
Pretojieties atiestatīšanai. Virtuālo saskarņu dzēšana, maršrutu tabulas iztīrīšana un IPv6 atslēgšana visā mašīnā iznīcina stāvokli, kas jums bija jāfiksē, un var līdzi paņemt nesaistītu konfigurāciju. Ja klientam ir atbalstīta pauzes, labošanas vai atinstalēšanas plūsma, izmantojiet to, un vietās, kur tīkls tiek pārvaldīts, ievērojiet administratora procedūru. Jau atiestatīta mašīna īpašniekam neko nedod, un tā parasti atkārto kļūmi nākamajā savienojumā.