VPN-Handshake-Schritte: Was geschieht, bevor Daten fließen

Ein Klick auf Verbinden startet vier getrennte Aufgaben, die unabhängig voneinander gelingen oder scheitern. Der Client muss einen Listener erreichen, sich über die Identität des Peers einigen, Schlüssel ableiten und dann einen funktionierenden Tunnel an das übrige System übergeben. Die meisten fehlgeschlagenen Verbindungen werden in der falschen Aufgabe diagnostiziert. Deshalb wiegt der erste Fehler mehr als der dritte Versuch.

Zuerst den Listener erreichen

Bevor irgendeine Identität ausgetauscht wird, löst der Client einen Namen auf, wählt eine Route und öffnet einen Transport zu einem Port. Ein Captive Portal, das alles beantwortet, ein geschlossener Port und ein falscher Hostname scheitern hier, und keines davon ist ein Authentifizierungsproblem. Ein Passwortwechsel kann keines der drei beheben. Lesen Sie die erste Zeile der Fehlermeldung, bevor Sie Zugangsdaten anfassen.

Ein Timeout, eine Zertifikatsablehnung und ein abgelehntes Konto sind drei verschiedene Störungen mit drei verschiedenen Prüfungen. Sie zuerst zu sortieren verhindert, dass ein Netzwerkproblem als Zugangsdatenproblem debuggt wird.

Den Peer ausweisen, dann Schlüssel ableiten

Jedes Protokoll braucht eine Möglichkeit, den vorgesehenen Server zu erkennen, sei es über einen konfigurierten öffentlichen Schlüssel oder eine Zertifikatskette. Eine Benutzeranmeldung kommt zu dieser Prüfung hinzu und ersetzt sie nicht. Ein Server, der Ihr Passwort annimmt, hat nichts über seine eigene Identität bewiesen. Deshalb ist ein in einen Client getipptes gemeinsames Geheimnis kein Ersatz dafür zu prüfen, wer geantwortet hat.

Der Austausch leitet dann Verkehrsschlüssel aus den eigenen Eingaben des Protokolls ab, und das Anmeldepasswort ist in der Regel nicht der Schlüssel, der auf jedes Paket gestempelt wird. Langfristiges Identitätsmaterial und kurzlebige Sitzungsschlüssel haben unterschiedliche Lebensdauern und unterschiedliche Aufgaben. Genau um diese Trennung geht es bei Forward Secrecy.

Lassen Sie die Prüfung bei der Fehlersuche aktiviert, denn ein Tunnel, der sich verbindet, nachdem Sie eine Prüfung deaktiviert haben, hat nichts bewiesen außer dass die Prüfung etwas getan hat. Notieren Sie, was Sie geändert haben, und stellen Sie es vor dem nächsten Test wieder her.

Drei Protokolle, drei Gespräche

Bei einem TLS-basierten OpenVPN-Einsatz handelt der Kontrollkanal Sicherheitsparameter aus, während der Datenkanal den Tunnelverkehr trägt, sodass eine Datenkanal-Option und ein Zertifikatsproblem an verschiedenen Stellen liegen. IKEv2 authentisiert beide Teilnehmer und baut dann IPsec-Sicherheitsassoziationen mit eigenen Laufzeiten auf. WireGuard leitet Schlüssel über seinen Noise-basierten Austausch ab und hält die Zustandsmaschine bewusst klein. Zu wissen, welches der drei Sie betreiben, entscheidet, welches Protokoll sich zu lesen lohnt.

Äußerlich ähnliche Clients bedeuten nicht austauschbare Nachrichten darunter, und ein Konfigurationsfeld, das es in einem Produkt gibt, hat in einem anderen möglicherweise kein Gegenstück. Ein Profil zwischen ihnen zu kopieren ist eine Vermutung und keine Migration.

Was der Handshake nicht leistet

Routen, Namensauflösung und Zielrichtlinie bleiben alle danach bestehen. Eine interne Seite kann unerreichbar bleiben, weil ihre Subnetzroute fehlt, obwohl der Peer korrekt authentisiert wurde und der Tunnel steht. Das als schwache Verschlüsselung zu behandeln schickt Sie in die falsche Ebene, und es endet meist mit einer Cipher-Änderung, die nichts repariert.

Schlüsselerneuerung und Wiederverbindung sehen in den meisten Statusanzeigen ebenfalls gleich aus, und keines von beiden sagt Ihnen, ob während der Unterbrechung normaler Verkehr blockiert war. Nur die Ausfallrichtlinie des Clients beantwortet diese Frage, also lesen Sie die Richtlinie statt das Symbol.

Arbeiten Sie die Stufen in der obigen Reihenfolge ab und halten Sie bei der ersten an, die einen Fehler erzeugt. Jede spätere Stufe erbt den Zustand der früheren, daher sagt ein Fehler in der dritten Stufe nichts über die vierte aus.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal