Jak sprawdzić stan IPv6 na Macu po rozłączeniu VPN

Dostęp do witryny przez IPv4 po zerwaniu tunelu nie dowodzi niczego o IPv6. macOS konfiguruje obie rodziny osobno, dla każdej usługi sieciowej, a klient VPN może zmienić jedną, nie ruszając drugiej. Przejdź przez trzy warstwy po kolei: konfiguracja adresu, wybór trasy, a potem dowolna polityka, którą klient instaluje w stanie rozłączenia. Przez cały czas nie zmieniaj sieci dostępowej, bo inaczej porównasz dwa różne problemy.

Zacznij od rodziny, która naprawdę się zepsuła

Strona, która ładuje się przez IPv4, mówi, że sieć fizyczna żyje. Nie mówi nic o tym, czy usługa ma globalny adres IPv6, czy prefiks jest nadal ogłaszany albo czy coś filtruje rodzinę. Potwierdź, co zawiodło, zanim wybierzesz narzędzie, bo nazwa, która rozwiązuje się na nieosiągalny adres, wygląda identycznie jak nazwa, która nie rozwiązuje się wcale. Zapytaj, która warstwa odpowiedziała źle, i zapisz odpowiedź. Bez tego każdy kolejny krok jest domysłem ubranym w procedurę.

Przez całe porównanie trzymaj tę samą sieć Wi-Fi i ten sam punkt dostępowy. Sieć kawiarni, która wczoraj oferowała IPv6, nic nie mówi o tej, w której jesteś teraz.

Przeczytaj adres przed trasą

W Ustawieniach systemowych panel TCP/IP aktywnej usługi pokazuje, czy IPv6 jest automatyczny, ręczny czy tylko lokalny łącza. Porównaj to z tym, czego oczekujesz, pamiętając, że organizacja mogła świadomie wybrać konfigurację ręczną. Następnie uruchom ifconfig i odczytaj odpowiedni interfejs. Sam adres fe80:: oznacza, że interfejs może rozmawiać z sąsiadami i nic więcej, więc obecność adresu lokalnego łącza nie jest dowodem użytecznej ścieżki.

Poszukaj też interfejsów utun, które klient zostawił. Przestarzałe urządzenie tunelowe może trzymać adres i trasę długo po tym, jak klient przestał go używać. Jeśli takie jest, to ustalenie cyklu życia dla właściciela klienta, a nie coś do natychmiastowego usunięcia.

Przeczytaj tablicę tras dla niedziałającego celu

Zapytaj jądro o cel, który zawiódł, a nie o trasę domyślną. route -n get 2001:db8::25 wypisuje interfejs i bramę wybrane dla tego adresu, a netstat -rn -f inet6 pokazuje całą tablicę do porównania. Trasa domyślna mówi, że domyślna istnieje; nie mówi, że ten cel jej używa.

Trzymaj DNS w osobnej przegrodzie. Resolver osiągalny przez IPv4 nadal może zwracać rekordy AAAA, więc błąd wyszukiwania i błąd routingu dają ten sam objaw w przeglądarce.

Oddziel politykę blokowania klienta od pozostałości

Niektórzy klienci są zaprojektowani tak, aby blokować ruch w stanie rozłączenia, w tym drugą rodzinę adresów, a to zachowanie jest funkcją, nie usterką.

Dowiedz się, jakie zachowanie dokumentuje twój klient, zanim potraktujesz blokadę jako uszkodzenie. scutil --dns pokazuje resolvery obowiązujące dla poszczególnych usług, i tam właśnie staje się widoczny resolver zainstalowany przez klienta albo ograniczone ustawienie DNS. Następnie sprawdź, czy zainstalowano i pozostawiono reguły filtra pakietów. Oczekiwana blokada i pozostała reguła wymagają przeciwnych reakcji, a rozdziela je tylko dokumentacja właściciela.

Zbierz dowody, potem zmień jedną rzecz

Zapisz wersję klienta, wersję macOS, usługę sieciową, zamierzoną politykę rozłączenia oraz wynik adresów i tras po obu stronach jednego cyklu połączenia i rozłączenia. Właśnie ten zapis zmienia skargę w problem cyklu życia, który ktoś może zbadać. Następnie wykonaj jedną zmianę i zmierz ponownie.

Oprzyj się resetowi. Usuwanie interfejsów wirtualnych, czyszczenie tablicy tras i wyłączanie IPv6 na całym komputerze niszczą stan, który trzeba było uchwycić, i mogą zabrać ze sobą niezwiązaną konfigurację. Jeśli klient ma obsługiwany przepływ pauzy, naprawy lub odinstalowania, użyj go i postępuj zgodnie z procedurą administratora tam, gdzie sieć jest zarządzana. Komputer, który już zresetowano, nie daje właścicielowi niczego do pracy i zwykle odtwarza usterkę przy następnym połączeniu.