Как да проверите състоянието на IPv6 на Mac след прекъсване на VPN
След прекъсване на VPN проверете адреса IPv6, маршрута към неуспешната дестинация и политиката за блокиране на клиента в този ред, преди каквото и да е нулиране.
Стигнете до сайт по 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 за цялата машина унищожават състоянието, което ви е трябвало да уловите, и могат да отнесат със себе си несвързана конфигурация. Ако клиентът има поддържан поток за пауза, поправка или деинсталиране, използвайте го и следвайте процедурата на администратора там, където мрежата се управлява. Машина, която вече е била нулирана, не дава на собственика нищо, с което да работи, и обикновено възпроизвежда дефекта при следващата връзка.