Warum sich ein OpenVPN-Profil nicht in SoftEther importieren lässt

Zwei Dateien, die beide wie eine VPN-Konfiguration aussehen, landen im selben Ordner, und nur eine davon funktioniert. Das OpenVPN-Profil beschreibt einen TLS-Tunnel mit Direktiven, die dieser Client versteht, während eine SoftEther-Verbindung eine Sitzung gegen einen virtuellen Hub mit einem anderen Authentifizierungsvertrag beschreibt. Das eine in das andere umzuwandeln ist keine Formatierungsübung, weil die beiden Clients nicht dasselbe Protokoll implementieren. Die Frage, welchen Dienst der Betreiber tatsächlich veröffentlicht hat, entscheidet über alles Folgende.

Zwei Dateien, zwei Verträge

Ein OpenVPN-Profil ist eine Client-Konfiguration: ein entfernter Endpunkt, ein Transport, TLS-Material und Direktiven für Routing und Neuverhandlung. Eine SoftEther-Verbindung ist eine native Client-Sitzung gegen einen virtuellen Hub, an die ein virtueller Adapter angehängt ist.

Sie können den Zugang zum selben Netz beschreiben, ohne austauschbar zu sein. Der OpenVPN-Listener ist eine Kompatibilitätsfunktion, die der Server auf einem separaten Port veröffentlichen kann, und er spricht OpenVPN statt des nativen Protokolls. Der native Client spricht das native Protokoll und erwartet sein eigenes Profil. Ein Server, zwei Türen, und jede Tür hat ihren eigenen Schlüssel.

Die Dateiendung verrät Ihnen fast nichts, deshalb ist die Antwort des Betreibers wichtiger als der Name der Datei.

Lesen Sie den Server, bevor Sie einen Zertifikatsblock anfassen

Fragen Sie den Betreiber drei Dinge: welcher Port und Transport, welche Authentifizierungsmethode und welcher Client erwartet wird. Diese Antworten beseitigen den größten Teil des Rätselratens.

Bestätigen Sie dann, was tatsächlich lauscht, statt was eine Anleitung behauptet. Ein deaktivierter Kompatibilitäts-Listener zeigt nichts auf seinem Port, und ein aktivierter zeigt einen Socket, selbst wenn sich nie jemand verbunden hat. Der Unterschied zwischen einem geschlossenen Port und einer abgelehnten Anmeldung ist die erste nützliche Diagnose. Alles danach hängt davon ab, an welche Tür geklopft wurde.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

Ein UDP-Port, der in der Liste der Listener fehlt, ist eine deaktivierte Funktion und kein Firewall-Problem.

Was der native Client braucht und ein Profil ihm nicht geben kann

Der native Client installiert einen virtuellen Netzwerkadapter und bindet eine Verbindung daran. Ohne diesen Adapter gibt es keine Schnittstelle zum Weiterleiten, weshalb eine native Verbindung sich authentifizieren und trotzdem keinen Verkehr führen kann.

Die native Authentifizierung läuft gegen einen virtuellen Hub, mit einem Benutzerobjekt, das der Hub-Administrator angelegt hat. Aus einem OpenVPN-Profil kopierte Zertifikatsblöcke werden keine Hub-Benutzer, und ein Hub-Benutzer wird kein Client-Zertifikat. Die beiden Systeme speichern Unterschiedliches, und ein Profil hat keinen Platz für den Benutzereintrag des Hubs. Das ist ein struktureller Unterschied und kein Syntaxproblem.

Halten Sie den privaten Schlüssel aus jedem Konvertierungsdienst heraus, denn ein Schlüssel, der den Rechner verlässt, muss als offengelegt gelten.

Was der OpenVPN-kompatible Listener annimmt

Der Kompatibilitäts-Listener ist aus Sicht des Clients ein echter OpenVPN-Server: Er erwartet einen OpenVPN-Client und die Direktiven, die dieser Client unterstützt. Inline-Zertifikatsblöcke sind eine OpenVPN-Funktion und gehören auf jene Seite des Zauns.

Was er nicht tut, ist ein natives SoftEther-Profil anzunehmen, denn dieses Profil ist keine OpenVPN-Konfiguration. Der Listener macht aus dem nativen Client auch keinen OpenVPN-Client. Bietet der Betreiber nur den nativen Dienst an, ist die Antwort der native Client; bietet er den Kompatibilitäts-Listener an, ist die Antwort OpenVPN und sein eigenes Material.

Bitten Sie um den unterstützten Export des Betreibers, anstatt einen aus Fragmenten zusammenzubauen, denn der Export trägt Details, die eine handgebaute Datei gewöhnlich übersieht.

Prüfen Sie den Pfad, bevor Sie Direktiven bearbeiten

Sobald der Client gewählt ist, testen Sie den Tunnel, bevor Sie Routen anfassen. Eine erfolgreiche Anmeldung und eine Schnittstelle, die Verkehr führt, sind zwei verschiedene Ergebnisse.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

Vergleichen Sie die zugewiesene Adresse mit dem Pool, den der Betreiber beschrieben hat, und schauen Sie dann getrennt auf Routen und Resolver. Eine native Hub-Verbindung kann sich sauber authentifizieren und überhaupt keine Routen installieren, was aus Client-Sicht wie ein kaputter Tunnel aussieht. Erst wenn diese drei übereinstimmen, lohnt es sich, eine Direktive zu bearbeiten. Früheres Bearbeiten verdeckt, welche Schicht falsch war.