Nativer SoftEther-Client oder OpenVPN-Profil: den richtigen Port wählen

Ein SoftEther-Server kann gleichzeitig auf dem nativen SSL-Port und auf einem OpenVPN-kompatiblen Port antworten, wodurch beide wie ein Dienst mit zwei Türen wirken. Es sind zwei Dienste mit unterschiedlichen Clients, unterschiedlichen Konfigurationsformaten und unterschiedlichen Fähigkeiten. Ein natives Profil in einen OpenVPN-Client zu laden, scheitert beim Parsen, und der Fehler sagt selten, warum.

Wählen Sie zuerst den Listener, dann den Client.

Zwei Listener, zwei Konfigurationsformate

Das native Protokoll nutzt einen SoftEther-Client und eine Verbindungsdefinition, die Server, Port, virtuellen Hub und Benutzer benennt. Der OpenVPN-kompatible Listener erwartet ein OpenVPN-Profil mit einer remote-Direktive, TLS-Material und Optionen aus einem viel kleineren unterstützten Satz, als ein eigenständiger OpenVPN-Server bietet. SoftEther nennt das eine OpenVPN-Klonfunktion, und Klon ist ein nützlicher Hinweis auf die Genauigkeit.

Kompatibilität ist eine Frage der Version. Prüfen Sie, was der eingesetzte Build akzeptiert, statt was ein aktuelles OpenVPN-Handbuch dokumentiert.

Schritt 1: Finden Sie heraus, welchen Listener der Betreiber aktiviert hat

Fragen Sie nach der Listener-Liste, statt aus einer Portnummer zu raten. Ein Server, der auf 443 TLS beantwortet, ist nicht unbedingt ein OpenVPN-Endpunkt, denn das native Protokoll kann denselben Port nutzen. Der Handbuchabschnitt zu kompatiblen Serverfunktionen beschreibt, welche Klone es gibt und wie sie aktiviert werden.

Wenn Sie den Host erreichen, testen Sie den Port, den Sie bekommen haben, statt den Port aus einem Tutorial: openssl s_client -connect vpn.example.com:443 -brief sagt Ihnen zumindest, ob TLS vorhanden ist.

Schritt 2: Verwenden Sie den passenden Client und das passende Profil

Für nativen Zugang installieren Sie den SoftEther-Client, legen eine Verbindung mit den Betreiberdaten an und hängen den virtuellen Adapter an. Für den kompatiblen Listener importieren Sie das OpenVPN-Profil, das der Betreiber vom Server exportiert hat, denn es enthält das CA- und Client-Material, das dieser Listener erwartet. Bauen Sie kein Profil von Hand aus einem generischen Beispiel zusammen, und fügen Sie keine native Verbindungsdefinition in eine OpenVPN-Konfiguration ein.

Ein Parse-Fehler beim Import ist ein Formatproblem, kein Netzwerkproblem, und er sollte Sie nicht zur Firewall schicken.

Schritt 3: Halten Sie den Vergleich ehrlich

Wenn der Betreiber beide veröffentlicht, vergleichen Sie sie, während Gerät, Zugangsnetz und Aufgabe gleich bleiben. Die beiden Wege können sich bei der Authentifizierung unterscheiden, in den Subnetzen, an die sie anknüpfen, und darin, was der Server danach mit Ihrem Verkehr macht. Ein gemeinsamer Host ist keine gemeinsame Richtlinie. Halten Sie auch die Aufgabe gleich, denn eine Dateikopie und ein Videoanruf belasten verschiedene Teile desselben Weges.

Widerstehen Sie den Korrekturen, die auftauchen, wann immer ein Import scheitert. Zertifikatsprüfungen abzuschalten oder alte Cipher zu aktivieren, um ein Profil durchzudrücken, ist ein Rückschritt, keine Kompatibilitätsfunktion.

Schritt 4: Prüfen Sie den Weg nach dem Verbinden

Prüfen Sie nach dem Verbinden die erhaltene Adresse, die mitgelieferten Routen, DNS und eine interne Ressource. Auf der nativen Seite ist der virtuelle Adapter die Schnittstelle, die zu prüfen ist; auf der OpenVPN-Seite ist es das tun- oder tap-Gerät, das der Client angelegt hat. So oder so ist die Frage, ob der gewählte Listener den Zugang ausgibt, den Sie brauchen, was ein separater Fakt davon ist, ob der Tunnel zustande kam. Notieren Sie die Adresse vorher und nachher und vergleichen Sie sie.

Notieren Sie, welcher Listener und welche Client-Version das funktionierende Ergebnis erzeugt haben. Die nächste Person würde die Entdeckung sonst von der Portnummer an wiederholen.