Як перевірити стан 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 на всій машині знищують стан, який потрібно було зафіксувати, і можуть потягти за собою не пов'язану конфігурацію. Якщо у клієнта є підтримуваний сценарій паузи, відновлення або видалення, скористайтеся ним і дотримуйтеся процедури адміністратора там, де мережею керують. Машина, яку вже скинули, нічого не дає власникові для роботи, і зазвичай відтворює дефект під час наступного підключення.