VPN na Macu łączy się raz, potem następuje przekroczenie czasu: wyczyść demona IKE

Pierwsze połączenie po ponownym uruchomieniu działa. Każda kolejna próba zawiesza się na etapie łączenia i w końcu kończy się przekroczeniem czasu, a jedynym niezawodnym lekarstwem jest kolejne uruchomienie. Ten wzorzec nie jest problemem profilu i nie jest problemem danych logowania. Coś w tle wciąż trzyma stan z poprzedniej próby, a następna próba się z nim zderza.

W macOS tym czymś jest zwykle demon IKE.

Wzorzec: jedno połączenie, potem przekroczenie czasu

Połączenie, które działa dokładnie raz na uruchomienie, wskazuje na stan, który przeżywa rozłączenie, ale nie ponowne uruchomienie. Profile przeżywają oba, więc profil nie jest zmienną. Dane logowania również przeżywają oba, chyba że serwer zablokuje konto. To, co zmienia się przy ponownym uruchomieniu, to zbiór działających demonów i gniazda, które trzymają.

To zawęża dochodzenie, zanim otworzysz choć jeden log. Pytanie staje się, który proces posiada port IKE i co uważa, że robi.

Dwa demony, jeden port

System uruchamia racoon gdy połączenie mówi wersją IKE 1. Bieżące wydania wprowadzają też iked dla IKEv2 i nowszego stosu IPsec. Oba mogą zająć UDP 500 i UDP 4500, a oba mogą utrzymać na wpół otwartą asocjację bezpieczeństwa po anulowaniu próby połączenia przy monicie o hasło lub przerwaniu przez zmianę sieci.

Kiedy tak się dzieje, następna próba nie zaczyna się czysto. Próbuje negocjować, podczas gdy stara asocjacja wciąż zajmuje stan peera, a wymiana utyka zamiast zakończyć się jasnym błędem. Użytkownik widzi kręcący się wskaźnik, a potem przekroczenie czasu.

Znajdź właściciela, zanim cokolwiek zabijesz, bo odpowiedź decyduje, którą usługę uruchomisz ponownie i który log przeczytasz dalej.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Czytaj wynik jako dwa fakty: który proces trzyma port i czy jest ich więcej niż jeden. Dwa demony IKE konkurujące o to samo gniazdo wyjaśniają wiele nieregularnych zachowań, które wyglądają jak niestabilny serwer.

Uruchom ponownie zadanie, a nie proces

W starszych systemach wystarczy zabić proces i pozwolić następnemu połączeniu uruchomić go ponownie. W bieżących wydaniach demonem zarządza launchd, a samo wysłanie sygnału do procesu może zostawić zadanie w stanie, w którym ani nie działa, ani nie jest zaplanowane do startu. Zatrzymaj i uruchom zadanie.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Jeśli launchd nie ma wpisu o zadaniu, zabicie procesu po nazwie nadal wymusza świeże negocjacje przy następnej próbie. Test jest taki sam w obu przypadkach: żaden proces nie powinien trzymać portu, gdy próbujesz połączyć się ponownie. Potwierdź to tym samym poleceniem lsof zamiast zakładać, że ponowne uruchomienie zadziałało.

Potem połącz się raz i przeczytaj log klienta od początku. Negocjacje, które przechodzą fazę 1, a potem zgłaszają błąd transmisji, powtarzają lokalny problem z gniazdem; negocjacje odrzucone przez peera to zupełnie inny bilet.

Kiedy to serwer odmawia

Nie każde drugie połączenie zawodzi lokalnie. Serwer może odmówić nowego logowania przez ustalone okno po rozłączeniu, a przekroczenie czasu u klienta wygląda identycznie jak zawieszony demon. Rozróżnienie jest tanie: jeśli ponowne uruchomienie demona nie pomaga, ale inne konto łączy się natychmiast, okno jest po stronie serwera i Mac nigdy nie był problemem.

Polityka tunelu dzielonego tworzy ten sam kształt z drugiej strony. Serwer, który wymaga całego ruchu w tunelu, odrzuci klienta skonfigurowanego do tunelu dzielonego podczas negocjacji, a klient zgłosi przekroczenie czasu zamiast odrzucenia polityki. Zmiana profilu, aby wszystko szło przez tunel, może pozwolić mu się połączyć, ale to decyzja polityczna do podjęcia z właścicielem sieci, a nie naprawa do cichego zastosowania.

Przeczytaj log peera, zanim znowu zmienisz klienta. Odrzucenie, niezgodność polityki i ciche odrzucenie to trzy różne przyczyny, które na ekranie Maca wyglądają tak samo jak „łączenie”.

Starsi klienci i jądro 64-bitowe

Stary klient Cisco IPSec ładuje rozszerzenie jądra zbudowane dla systemów 32-bitowych i PowerPC. Na Macu uruchomionym z jądrem 64-bitowym to rozszerzenie nie może się załadować, a klient zawodzi wcześnie z błędem 51, bo w ogóle nie dociera do podsystemu VPN. Żadna liczba ponownych uruchomień demona nie naprawi rozszerzenia jądra o złej architekturze.

Ponowne załadowanie rozszerzenia może działać przez chwilę, a potem znowu zawieść przy następnym uruchomieniu. Trwałe odpowiedzi to uruchomienie starszego jądra tam, gdzie jest jeszcze obsługiwane, albo przejście na wbudowanego klienta dostarczanego z systemem. Sprawdź architekturę, zanim spędzisz wieczór z klientem innej firmy, którego nie da się załadować.

• Odtwórz raz, a potem sprawdź, który demon posiada UDP 500, zanim dotkniesz profilu.
• Przeczytaj pierwszy błąd po fazie 1: błąd transmisji wskazuje lokalne gniazdo.
• Uruchom ponownie zadanie launchd, nie tylko proces, i potwierdź, że port jest wolny.
• Wypróbuj drugie konto, aby oddzielić okno ponownej uwierzytelniania po stronie serwera od usterki klienta.
• Zapisz architekturę jądra, zanim obwinisz klienta.

VPN, który działa dokładnie raz, jest problemem stanu, dopóki nie zostanie dowiedzione inaczej. Wyczyszczenie demona jest szybsze niż ponowne uruchomienie i zachowuje dowody z logów, które ponowne uruchomienie by wyrzuciło.