VPN na Macu zawiesza się na „Rozłączanie”: co naprawdę działa

Rozłączanie to przejście, nie zatrzymany tunel. Sprawdź, który komponent odpowiada za demontaż, przeczytaj trasy i DNS, i unikaj masowego zabijania procesów.

„Rozłączanie” to stan, który klient zgłasza podczas demontażu tunelu, a nie wyrok, że ruch się zatrzymał. Na Macu ten demontaż przebiega jako krótka sekwencja, a etykieta zmienia się dopiero po odpowiedzi komponentu, który posiada połączenie. Gdy jakiś krok czeka na pomocnika, wtyczkę lub decyzję polityki, etykieta może pozostać na miejscu po zniknięciu interfejsu albo tunel może nadal przekazywać, podczas gdy menu wciąż go pokazuje. Traktuj tekst jako „demontaż w toku, wynik nieznany” i ustal, która połowa jest prawdziwa.

Dwie awarie wyglądają z paska menu identycznie i wymagają przeciwnych reakcji. W jednej tunel nadal niesie pakiety i tylko wyświetlanie jest nieaktualne. W drugiej tunelu nie ma, ale osobna polityka trzyma ruch zablokowany, co często jest zamierzone. Trasy i stan DNS rozdzielają je szybciej niż jakakolwiek czynność w menu.

Co śledzi etykieta

Klient VPN utrzymuje małą maszynę stanów, a pasek menu jest jej projekcją. Dla połączenia zarządzanego przez sam macOS ta maszyna znajduje się w systemowej ramie VPN. Dla tunelu zarządzanego przez aplikację znajduje się w aplikacji i jej uprzywilejowanym pomocniku. Ostatnim krokiem zatrzymania nie jest zamknięcie gniazda. To zwolnienie tego, co czyniło tunel działającym: interfejsu utun, tras, które na niego wskazywały, wpisów resolvera wstawionych przez klienta oraz każdej reguły zapory lub polityki, która blokowała ruch podczas połączenia.

Te kroki są odrębne, więc zatrzymanie może utknąć na którymkolwiek z nich. Pomocnik, który przestaje odpowiadać, trasa, do której rości sobie prawo także drugi interfejs, lub wpis resolvera należący do innego profilu mogą pozostawić klienta w oczekiwaniu. Etykieta jest raportem o postępie samego klienta, co czyni ją wiarygodną co do intencji i niewiarygodną co do sieci.

Znajdź komponent, który posiada połączenie

W konfiguracjach natywnych scutil --nc list wypisuje usługi znane systemowi i ich stan, a scutil --nc status "Work VPN" podaje szczegóły jednej usługi. Tunel utrzymywany przez aplikację innej firmy może w ogóle nie pojawić się na tej liście, więc pusty wynik nie jest dowodem, że nic nie jest połączone.

Gdy profil należy do aplikacji, polegaj na jej widoku stanu i udokumentowanym elemencie „Rozłącz”. Zamknięcie okna nie jest żądaniem zatrzymania, jeśli tunelem zarządza pomocnik w tle; ikona znika, a pomocnik utrzymuje interfejs przy życiu. Dokumentacja Apple dotycząca ustawień VPN omawia natywne elementy sterujące i pochodzenie ustawień zarządzanych.

Czytaj interfejsy, trasy i DNS

Trzy kontrole odpowiadają na większość pytania bez dotykania połączenia. Ważna jest ich wspólna interpretacja, bo każda osobno wprowadza w błąd.

scutil --nc list
netstat -rn -f inet | head -20
ifconfig | grep -A 3 '^utun'
scutil --dns | head -30
  • interfejs utun istnieje, prowadzi przez niego trasa domyślna lub dzielona, resolver wskazuje dostawcę: tunel nadal stoi, a etykieta jest nieaktualna.
  • brak utun, zwykła trasa domyślna, DNS z DHCP, brak internetu: polityka blokująca po rozłączeniu robi swoje.
  • brak utun, brak trasy, resolver nadal wskazuje dostawcę: demontaż zatrzymał się w połowie, a DNS jest resztką do wyczyszczenia.

Potem wyślij jedno żądanie do hosta wewnętrznego, który powinien odpowiadać tylko przez tunel, i jedno do hosta publicznego. Osiągalność oddziela politykę od stanu resztkowego, nie zamieniając kontroli w ćwiczenie pomiarowe. Najpierw zapisz pracę zdalną, jeśli ścieżka jeszcze odpowiada, i zapewnij drugą drogę wejścia, zanim zmienisz sieć na maszynie administrowanej zdalnie.

Dlaczego masowe zabijanie i usuwanie profilu wprowadzają w błąd

Nazwy procesów, takie jak pppd, racoon i configd, należą do konkretnych implementacji. Ich zabicie może wpłynąć na inne połączenia, zostawia trasy i interfejsy utun, i nie daje żadnego zapisu, na którym kroku utknęło. Stara nazwa procesu też nie jest dowodem, że posiada bieżący profil.

Usunięcie i ponowne utworzenie profilu to większa zmiana niż wyczyszczenie zablokowanego przejścia. Może wyrzucić ustawienia zarządzane i lokalny materiał tożsamości bez wyjaśnienia, co zawiodło, a na nadzorowanym Macu może po prostu zostać przywrócony. Zostaw usuwanie dla konfiguracji naprawdę przestarzałej i zamiast tego diagnozuj przejście.

Sekwencja zatrzymania, która zostawia ślad

Poniższa kolejność pozostawia elementy sterujące samego połączenia odpowiedzialnymi i tworzy zapis, jeśli zawieszenie wróci. Chroni cię też przed zamianą problemu z wyświetlaniem w zmianę sieci.

  1. Zapisz pracę zdalną i potwierdź, że dotrzesz do Maca inaczej, jeśli jest zdalny.
  2. Zanotuj nazwę klienta, wersję i profil. Przechwyć krótkie okno za pomocą log show --last 5m --predicate 'subsystem == "com.apple.networkextension"'; starsze wersje zachowują mniej historii, więc uruchom to wkrótce po zawieszeniu.
  3. Użyj udokumentowanego elementu „Rozłącz”, poczekaj, a potem powtórz kontrole interfejsu i tras.
  4. Jeśli etykieta jest nieaktualna, ale tunel jest wyłączony, zostaw ją i pozwól klientowi się odświeżyć zamiast wymuszać procesy.
  5. Jeśli demontaż naprawdę utknął, uruchom klienta ponownie, a następnie zaplanuj restart Maca po zapisaniu pracy. Maszyny zarządzane wymagają procedury administratora.

Po odzyskaniu potwierdź, że zwykła trasa domyślna i resolver DHCP wróciły, a zablokowany ruch jest albo przywrócony, albo celowo nadal zablokowany. Zanotuj profil i wersję klienta wraz z objawem, aby następne wystąpienie zaczynało się od dowodów, a nie od zgadywania w pasku menu.

Powiązane artykuły