Як праверыць стан IPv6 на Mac пасля адключэння VPN

Наведайце сайт праз IPv4 пасля падзення тунеля — і вы нічога не даказалі пра IPv6. macOS наладжвае дзве сям'і асобна, для кожнай сеткавай службы, і кліент VPN можа змяніць адну, не закранаючы другую. Праходзьце тры ўзроўні па парадку: канфігурацыя адраса, выбар маршруту, а затым любая палітыка, якую кліент усталёўвае ў адключаным стане. Тым часам пакіньце сетку доступу нязменнай, інакш вы будзеце параўноўваць дзве розныя праблемы.

Пачніце з сям'і, якая насамрэч зламалася

Старонка, якая загружаецца праз IPv4, кажа вам, што фізічная сетка жывая. Яна нічога не кажа пра тое, ці мае служба глабальны адрас IPv6, ці ўсё яшчэ абвяшчаецца прэфікс, ці нешта фільтруе гэтую сям'ю. Пацвердзіце, што менавіта зламалася, перш чым выбіраць інструмент, бо імя, якое разрозніваецца ў недасяжны адрас, выглядае гэтак жа, як імя, якое не разрозніваецца зусім. Спытайце, які ўзровень адказаў памылкова, і запішыце адказ. Без гэтага кожны наступны крок — здагадка, апранутая ў працэдуру.

Трымайце тую ж сетку Wi-Fi і тую ж кропку доступу ўвесь час параўнання. Сетка кавярні, якая ўчора прапаноўвала IPv6, нічога не кажа пра тую, у якой вы знаходзіцеся цяпер.

Прачытайце адрас перад маршрутам

У Сістэмных наладах панэль TCP/IP актыўнай службы паказвае, ці IPv6 наладжаны аўтаматычна, уручную або толькі лакальна для злучэння. Параўнайце гэта з тым, што вы чакаеце, памятаючы, што арганізацыя магла наўмысна выбраць ручную канфігурацыю. Затым выканайце ifconfig і прачытайце адпаведны інтэрфейс. Адрас fe80:: сам па сабе азначае, што інтэрфейс можа гаварыць са сваімі суседзямі і не больш, таму наяўнасць лакальнага адраса не з'яўляецца доказам прыдатнага шляху.

Шукайце таксама інтэрфейсы utun, якія кліент пакінуў пасля сябе. Старая прылада тунеля можа ўтрымліваць адрас і маршрут яшчэ доўга пасля таго, як кліент спыніў яе выкарыстоўваць. Калі такая ёсць, гэта знаходка жыццёвага цыкла для ўладальніка кліента, а не рэч, якую трэба выдаліць адразу.

Прачытайце табліцу маршрутаў для збойнай прызначэння

Спытайце ядро пра прызначэнне, якое не ўдалося, а не пра маршрут па змаўчанні. route -n get 2001:db8::25 друкуе інтэрфейс і шлюз, выбраныя для гэтага адраса, а netstat -rn -f inet6 паказвае ўсю табліцу для параўнання. Маршрут па змаўчанні кажа вам, што значэнне па змаўчанні існуе; ён не кажа, што гэтае прызначэнне выкарыстоўвае яго.

Трымайце DNS у асобным аддзеле. Рэзалвер, дасяжны праз IPv4, усё яшчэ можа вяртаць запісы AAAA, таму збой пошуку і збой маршрутызацыі даюць аднолькавы сімптом у браўзеры.

Аддзяліце палітыку блакіроўкі кліента ад пакінутых правіл

Некаторыя кліенты створаны для блакіроўкі трафіку ў адключаным стане, уключаючы іншую сям'ю адрасоў, і гэтыя паводзіны — асаблівасць, а не збой.

Высветліце, якія паводзіны апісвае дакументацыя вашага кліента, перш чым лічыць блакіроўку пашкоджаннем. scutil --dns паказвае рэзалверы, што дзейнічаюць для кожнай службы, і менавіта там становіцца бачным усталяваны кліентам рэзалвер або DNS-налада з абмежаваннем. Затым праверце, ці былі ўсталяваныя і пакінутыя правілы фільтра пакетаў. Чаканая блакіроўка і пакінутае правіла патрабуюць процілеглых адказаў, і толькі дакументацыя ўладальніка адрознівае іх.

Захавайце доказы, затым змяніце адно

Запішыце версію кліента, версію macOS, сеткавую службу, меркаваную палітыку ў адключаным стане, а таксама вывад адрасоў і маршрутаў на абодвух баках аднаго цыкла падключэння і адключэння. Менавіта гэты запіс ператварае скаргу ў праблему жыццёвага цыкла, якую хтосьці можа даследаваць. Затым зрабіце адзіную змену і зноў вымерайце.

Супраціўляйцеся скіду. Выдаленне віртуальных інтэрфейсаў, ачыстка табліцы маршрутаў і адключэнне IPv6 на ўсёй машыне знішчаюць стан, які вам трэба было захаваць, і могуць пацягнуць за сабой незвязаную канфігурацыю. Калі кліент мае падтрыманы сцэнар паўзы, рамонту або выдалення, скарыстайцеся ім і прытрымлівайцеся працэдуры адміністратара там, дзе сетка кіруецца. Машына, якая ўжо была скідзеная, не дае ўладальніку нічога, з чым можна працаваць, і звычайна аднаўляе збой пры наступным падключэнні.