WireGuard-Profil für ein IPsec-Gateway: Was man stattdessen erfragen sollte

Handshake-Zeitüberschreitungen an einem stillen Gateway bedeuten meist zwei Protokolle, die nie zusammentreffen. Ein WireGuard-Peer spricht Noise, während ein IPsec-Gateway auf IKE wartet. Eine korrekte Adresse und ein korrekter Port ändern daran nichts.

Die Wiederverwendung des Endpunkts in einem Profil überbrückt die beiden nicht. Der nächste Schritt ist eine Anfrage an denjenigen, der das Gateway betreibt.

Anfrage eins: die Protokollversion

IPsec bezeichnet eine Familie und nicht einen einzelnen Ablauf. IKEv2 und IKEv1 unterscheiden sich in ihren Aushandlungen, ihren Authentifizierungsoptionen und ihrem Verhalten bei einem Netzwerkwechsel. Ein Gateway, das nur IKEv1 terminiert, verhält sich ganz anders als eines, das IKEv2 anbietet. Die Clientkonfiguration unterscheidet sich entsprechend.

Fragen Sie, welche Version der Dienst terminiert und ob er eine standardkonforme Implementierung oder eine Herstellervariante mit eigenem Client betreibt. Betriebssystemmenüs verbergen diese Antwort oft hinter einem einzigen Label. Das Label ist nicht das Protokoll.

Anfrage zwei: die Authentifizierungsmethode des Clients

Die Authentifizierung ist der Punkt, an dem der größte Teil der eigentlichen Arbeit liegt. Der Dienst erwartet möglicherweise ein Maschinenzertifikat mit einer bestimmten erweiterten Schlüsselverwendung, ein Benutzerzertifikat, eine EAP-Methode über IKEv2 oder einen vorab vereinbarten Schlüssel, der an eine Identität gebunden ist. Welche Variante gilt, entscheidet darüber, was der Client benötigt.

Ein privater WireGuard-Schlüssel ist nichts davon. Er ist ein Curve25519-Schlüssel, der in genau einer Handshake-Variante verwendet wird. Keine Konvertierung macht daraus ein Zertifikat oder eine EAP-Anmeldeinformation. Ein Werkzeug, das etwas anderes behauptet, benennt die Datei um oder erzeugt etwas Unzusammenhängendes.

Die IKEv2-Spezifikation in RFC 7296 beschreibt, was eine Implementierung dieser Version unterstützen muss. Sie ist eine Referenz für eine vage Betreiberauskunft, kein Leitfaden zur Clientkonfiguration.

Anfrage drei: die vertrauenswürdige Identität und die Ziele

Fragen Sie nach der Gateway-Identität, wie der Client sie sehen muss, sowie nach dem Vertrauensanker, der sie validiert. Fragen Sie dann, welche privaten Bereiche und Resolver der Dienst übermittelt. Diese beiden Antworten entscheiden darüber, was der Tunnel tatsächlich befördert.

Ohne sie kann eine funktionierende Verbindung die Aufgabe trotzdem verfehlen. Ein Tunnel, der steht, aber keinen übermittelten Resolver hat, lässt interne Namen unbeantwortet. Ein fehlender Traffic-Selector lässt das Ziel außerhalb des Tunnels, obwohl der Handshake erfolgreich war.

Eine Prüfung des Endpunkts beantwortet eine andere Frage als der Clientfehler. Ein erreichbarer Port ohne Assoziation deutet auf die Authentifizierung hin, ein nicht erreichbarer Port auf den Pfad.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Führen Sie diese Prüfung aus, bevor Sie irgendetwas am Client ändern. Antworten die Ports und scheitert die Assoziation weiterhin, liegt das Problem an den Anmeldeinformationen oder an der Richtlinie. Antworten sie gar nicht, hilft keine Profiländerung.

Wenn beide Protokolle koexistieren müssen

Beide Netzwerke zu verwalten ist ein legitimer Grund, beide Protokolle zu behalten. Das übliche Design terminiert WireGuard und IPsec auf getrennten Schnittstellen oder getrennten Gateways. Der genehmigte Verkehr wird dann zwischen ihnen geroutet.

Dieses Design führt eine Vertrauens- und Autorisierungsgrenze ein, und sie sollte als solche schriftlich festgehalten werden. Welche Peers hinüberwechseln dürfen, in welche Richtung und unter wessen Richtlinie, ist eine Routing- und Firewall-Entscheidung. Keines der beiden Protokolle liefert sie.

Was es nicht ist, ist eine transparente Konvertierung. Verkehr, der über WireGuard ankommt, wird in den IPsec-Tunnel neu ausgeleitet, und jede Richtlinie dazwischen gilt dafür.

Klären Sie zuerst die Protokoll- und Authentifizierungsanforderungen des Servers. Nutzen Sie dann den Client und den Registrierungspfad, die der Betreiber unterstützt, und halten Sie private Schlüssel währenddessen aus Web-Konvertern heraus.