Mac-VPN verbindet einmal und läuft dann in einen Timeout: IKE-Daemon bereinigen

Die erste Verbindung nach einem Neustart funktioniert. Jeder weitere Versuch hängt in der Verbindungsphase und läuft schließlich in einen Timeout, und das einzige verlässliche Mittel ist ein weiterer Neustart. Dieses Muster ist kein Profilproblem und kein Problem der Zugangsdaten. Etwas im Hintergrund hält noch den Zustand des vorherigen Versuchs, und der nächste Versuch kollidiert damit.

Unter macOS ist dieses Etwas meist der IKE-Daemon.

Das Muster: einmal verbinden, dann Timeout

Eine Verbindung, die genau einmal pro Start funktioniert, deutet auf Zustand hin, der ein Trennen übersteht, einen Neustart aber nicht. Profile überstehen beides, also ist das Profil nicht die Variable. Zugangsdaten überstehen beides ebenfalls, es sei denn, der Server sperrt das Konto. Was sich beim Neustart ändert, ist die Menge laufender Daemons und der Sockets, die sie halten.

Das verengt die Untersuchung, bevor Sie auch nur ein Protokoll öffnen. Die Frage wird, welcher Prozess den IKE-Port besitzt und was er zu tun glaubt.

Zwei Daemons, ein Port

Das System startet racoon wenn eine Verbindung IKE Version 1 spricht. Aktuelle Versionen bringen auch iked für IKEv2 und den neueren IPsec-Stack mit. Beide können UDP 500 und UDP 4500 binden, und beide können eine halboffene Sicherheitsassoziation behalten, nachdem ein Verbindungsversuch an der Passwortabfrage abgebrochen oder durch einen Netzwerkwechsel unterbrochen wurde.

Wenn das passiert, startet der nächste Versuch nicht sauber. Er versucht zu verhandeln, während die alte Assoziation noch den Zustand des Peers belegt, und der Austausch bleibt stehen, statt mit einem klaren Fehler zu scheitern. Der Nutzer sieht einen Spinner und dann einen Timeout.

Finden Sie den Besitzer, bevor Sie etwas beenden, denn die Antwort bestimmt, welchen Dienst Sie neu starten und welches Protokoll Sie als Nächstes lesen.

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

Lesen Sie die Ausgabe als zwei Fakten: welcher Prozess den Port hält und ob mehr als einer vorhanden ist. Zwei IKE-Daemons, die um denselben Socket konkurrieren, erklären viel unregelmäßiges Verhalten, das wie ein instabiler Server aussieht.

Starten Sie den Job neu, nicht den Prozess

Auf älteren Systemen genügt es, den Prozess zu beenden und die nächste Verbindung ihn neu starten zu lassen. In aktuellen Versionen wird der Daemon von launchd verwaltet, und ein Signal nur an den Prozess kann den Job in einem Zustand zurücklassen, in dem er weder läuft noch zum Start eingeplant ist. Stoppen und starten Sie stattdessen den Job.

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

Hat launchd keinen Eintrag für den Job, erzwingt das Beenden des Prozesses nach Namen beim nächsten Versuch trotzdem eine frische Verhandlung. Der Test ist in beiden Fällen gleich: kein Prozess sollte den Port halten, wenn Sie erneut verbinden. Bestätigen Sie das mit demselben Befehl lsof statt anzunehmen, dass der Neustart funktioniert hat.

Verbinden Sie dann einmal und lesen Sie das Client-Protokoll von Anfang an. Eine Verhandlung, die über Phase 1 hinausgeht und dann einen Übertragungsfehler meldet, wiederholt das lokale Socket-Problem; eine vom Peer abgelehnte Verhandlung ist ein völlig anderes Ticket.

Wenn der Server derjenige ist, der ablehnt

Nicht jede zweite Verbindung scheitert lokal. Ein Server kann ein neues Login für ein festes Fenster nach einer Trennung ablehnen, und der Timeout des Clients sieht identisch aus wie ein hängender Daemon. Die Unterscheidung ist billig: Hilft ein Neustart des Daemons nicht, verbindet sich aber ein anderes Konto sofort, liegt das Fenster auf der Serverseite und der Mac war nie das Problem.

Die Split-Tunnel-Richtlinie erzeugt dieselbe Form aus der anderen Richtung. Ein Server, der den gesamten Traffic im Tunnel verlangt, verwirft einen für Split-Tunneling konfigurierten Client während der Verhandlung, und der Client meldet einen Timeout statt einer Richtlinienablehnung. Das Profil so zu ändern, dass alles durch den Tunnel geht, kann die Verbindung herstellen, aber das ist eine Richtlinienentscheidung, die mit dem Netzwerkeigentümer zu treffen ist, keine stillschweigend anzuwendende Reparatur.

Lesen Sie das Protokoll des Peers, bevor Sie den Client erneut ändern. Eine Ablehnung, eine Richtlinienabweichung und ein stilles Verwerfen sind drei verschiedene Ursachen, die auf dem Mac-Bildschirm alle wie „verbindet“ aussehen.

Ältere Clients und der 64-Bit-Kernel

Der alte Cisco-IPSec-Client lädt eine Kernel-Erweiterung, die für 32-Bit- und PowerPC-Systeme gebaut wurde. Auf einem Mac, der in den 64-Bit-Kernel startet, kann diese Erweiterung nicht geladen werden, und der Client scheitert früh mit Fehler 51, weil er das VPN-Subsystem überhaupt nicht erreicht. Kein noch so häufiger Neustart des Daemons repariert eine Kernel-Erweiterung mit der falschen Architektur.

Ein erneutes Laden der Erweiterung kann eine Weile funktionieren und beim nächsten Start wieder scheitern. Dauerhafte Antworten sind, den älteren Kernel zu fahren, wo das noch unterstützt wird, oder auf den eingebauten Client zu wechseln, der mit dem System kommt. Prüfen Sie die Architektur, bevor Sie einen Abend mit einem Drittanbieter-Client verbringen, der sich nicht laden lässt.

• Reproduzieren Sie einmal und prüfen Sie dann, welcher Daemon UDP 500 besitzt, bevor Sie das Profil anfassen.
• Lesen Sie den ersten Fehler nach Phase 1: Ein Übertragungsfehler deutet auf den lokalen Socket hin.
• Starten Sie den launchd-Job neu, nicht nur den Prozess, und bestätigen Sie, dass der Port frei ist.
• Probieren Sie ein zweites Konto, um ein serverseitiges Reauth-Fenster von einem Clientfehler zu trennen.
• Notieren Sie die Kernel-Architektur, bevor Sie dem Client die Schuld geben.

Ein VPN, das genau einmal funktioniert, ist ein Zustandsproblem, bis das Gegenteil bewiesen ist. Den Daemon zu bereinigen ist schneller als ein Neustart, und es bewahrt die Protokollbeweise, die ein Neustart verworfen hätte.