OpenVPN oder IKEv2: vier Prüfungen, bevor Sie ein Protokoll wählen

Die Entscheidung zwischen OpenVPN und IKEv2 wird meist als Protokollfrage diskutiert, und diese Sichtweise verschwendet die Entscheidung. Was sie wirklich entscheidet, ist, ob Ihr Server und Ihre Geräte dasselbe vollständige Profil unterstützen und ob dieses Profil die Art übersteht, wie Sie zwischen Netzen wechseln. Die beiden Stapel lassen sich nicht ineinander übersetzen: Eine OVPN-Datei ist kein IKEv2-Profil mit anderer Syntax. Vier Prüfungen, der Reihe nach ausgeführt, beantworten die Frage schneller als jede Funktionsmatrix.

Ein fehlender Client beendet die Diskussion

Windows und macOS bringen einen IKEv2-Client mit, ein IKEv2-Profil kostet dort also nichts extra bei der Bereitstellung und erbt die Bereitstellungsoptionen, die das Betriebssystem bereits anbietet. OpenVPN auf denselben Rechnern bedeutet dagegen einen Drittanbieter-Client, der installiert, aktualisiert und unterstützt werden muss, und dieser Client muss jede Option akzeptieren, die das Profil nutzt. Zählen Sie die Plattformen, die Sie abdecken müssen, bevor Sie irgendetwas anderes vergleichen, denn eine Plattform ohne funktionierenden Client ist überhaupt kein Vergleichspunkt.

Unter Windows listet ein Befehl die bereits vorhandenen Profile auf und zeigt, welchen Typ jedes hat. Der ausgegebene Name ist der Name, den die späteren Prüfungen verwenden.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

Die Aufforderung, einen Client zu installieren, ist auf diesen Plattformen die tatsächliche Antwort für die OpenVPN-Spalte, und sie ist eine Bereitstellungsaufgabe und keine Protokollbeschränkung. Keine der beiden Varianten erspart Vertrauensprüfungen, Identitätsverifikation oder Wartung. Fragen Sie, wie Profile verteilt werden, wie Zugangsdaten erneuert werden und wie ein verlorenes Gerät entfernt wird, bevor Sie sich festlegen. Eine einfache Installation kann immer noch einen Wiederherstellungsprozess verbergen, den am Wochenende niemand ausführen möchte.

Mobilität ist eine gemeinsame Einstellung, kein Protokollversprechen

IKEv2 kann MOBIKE nutzen, wenn beide Seiten es unterstützen und aktivieren, was einem Client erlaubt, seinen Tunnel zu behalten, während sich seine Adresse ändert. RFC 4555 definiert die Erweiterung, und die bedingte Formulierung ist wichtig: Ein Server, der die Fähigkeit ignoriert, handelt stattdessen neu. Das Ergebnis kann bei einer Dateiübertragung identisch aussehen und bei einem laufenden Gespräch sehr unterschiedlich.

Testen Sie den Übergang, der Ihnen wirklich wichtig ist, mit etwas Laufendem, das Sie beobachten können. Lassen Sie ping -t <internal-host> unter Windows weiterlaufen, oder das schlichte ping an anderer Stelle, dann wechseln Sie von WLAN zu Mobilfunk und achten Sie auf Lücken. Ein MOBIKE-Fehler erscheint im Client-Protokoll als vollständige Neuanmeldung statt als stilles Adressupdate. Was Sie messen, ist, ob der Tunnel den Wechsel übersteht, und nicht, ob das Protokoll Unterstützung bewirbt.

OpenVPN-Clients verbinden sich je nach Plattformverhalten und Profil-Timern neu, daher kann derselbe Test eine andere Form der Unterbrechung erzeugen. Vergleichen Sie das Ereignis, das für Ihre Nutzer zählt, und nicht das Etikett auf dem Protokoll.

Zugangsdaten gehören zum Dienst, nicht zum Stapel

Zertifikate und andere Anmeldeverfahren gehören zu dem Dienst, der die Verbindung beendet. Eine Passwortabfrage in einem Client sagt nichts über die Kompatibilität mit einem anderen aus, und ein Profil, das gegen ein anderes Gateway funktioniert, sagt nichts über dieses hier aus. Lassen Sie die Regeln für die Serveridentität intakt, während Sie die beiden Stapel vergleichen. Ein Protokollwechsel, bevor Sie den Fehler identifiziert haben, erzeugt meist ein zweites inkompatibles Profil.

Prüfen Sie die Zugangsdaten, die der Client vorlegen wird, bevor Sie eines der Protokolle beschuldigen, denn ein abgelaufenes oder falsch ausgestelltes Zertifikat scheitert bei beiden auf dieselbe Weise. Die Ausgabe unten zeigt Betreff, Aussteller und Gültigkeitsdaten, ohne den privaten Schlüssel zu lesen.

openssl x509 -in client.crt -noout -subject -issuer -dates

Verwenden Sie für eine Firmenverbindung die Methode, die die Firma veröffentlicht, und hören Sie auf, den Vergleich als Experiment zu behandeln. Wenn Sie die beiden für sich selbst vergleichen, prüfen Sie zuerst, ob beide Optionen an einem Gateway enden, denn dieses eine Detail entscheidet, wie viel Ihres Ergebnisses vom Protokoll handelt. Eine Ablehnung, die die Zugangsdaten nennt, ist ein Problem der Zugangsdaten, und kein Protokollwechsel wird sie reparieren.

Prüfen Sie, was der Tunnel tatsächlich weiterleitet

Bestätigen Sie nach dem Verbinden, dass die benötigte Route existiert und dass Namen aufgelöst werden. Ein Profil, das für interne Ressourcen existiert, kann das gewöhnliche Surfen planmäßig auf dem lokalen Weg belassen, und das ist eine Richtlinienentscheidung und kein Fehler. Entscheidend ist, ob die Ziele, die Ihr Team nutzt, durch den Tunnel erreichbar sind.

Zwei Befehle decken unter Windows die Route und die Namensauflösung ab. Die Linux-Entsprechungen sind ip route show default und resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

Ein Tunnel, der hochkommt und nichts Nützliches weiterleitet, ist ein häufiges Ergebnis, wenn ein Profil zwischen Diensten kopiert wurde, und ein allgemeiner Konnektivitätstest zeigt es nicht, weil die Schnittstelle oben ist. Testen Sie die Ressource, die Ihre Nutzer zuerst öffnen, nicht eine öffentliche Adresse, die jeder Weg erreicht. Wenn der Name auf eine öffentliche Adresse auflöst, während die Route in den Tunnel zeigt, gehören die DNS-Antwort und die Route zu unterschiedlichen Entscheidungen und beide müssen korrigiert werden.

Wägen Sie die Wartung nach den Prüfungen ab

Keines der Protokolle ist im Abstrakten wartbarer. Die Wartung hängt davon ab, wer das Gateway betreibt, wie Profile zu Geräten gelangen und wie schnell ein verlorenes Gerät den Zugang verliert. Ein einfacher Endpunkt-Client kann vor einem schwieriger zu betreibenden Server sitzen, und das Umgekehrte kommt ebenfalls vor. Fragen Sie, welches der beiden Ihr Team weiter betreiben kann, nachdem die Person, die es gebaut hat, gegangen ist.

Wählen Sie die unterstützte Verbindung, die die Arbeit abdeckt, und testen Sie sie dann gegen den Zugang, den Sie tatsächlich brauchen, statt gegen eine Funktionsliste. Halten Sie fest, an welchem Gateway jede Option endet, denn zwei verschiedene Gateways machen den Vergleich ebenso sehr zu einer Frage der Routen wie der Protokolle. Wiederholen Sie die vier Prüfungen auf dem Gerät, das Sie tatsächlich mitnehmen werden, und behalten Sie das Profil, das darauf besteht.