Welche Protokolle bietet dieser öffentliche VPN-Knoten wirklich an?

Die Software unterstützt es, also bietet der Knoten es an. Dieser Schluss ist oft genug falsch, um eine Regel zu sein: Eine SoftEther-Bereitstellung kann jede beliebige Teilmenge ihrer kompatiblen Verbindungsmethoden aktivieren, und ein öffentlicher Knoten ist eine Bereitstellung mit einem Betreiber und einer Konfiguration. Womit Sie sich verbinden können, hängt von diesem Knoten ab, nicht von der Funktionsliste des Projekts, das er ausführt. Genau in der Lücke zwischen beidem leben die meisten Tickets der Art „das Protokoll ist kaputt“.

Was die Projektliste tatsächlich verspricht

Die Protokollfunktionen des Projekts beschreiben, wozu der Server fähig ist. Ein gegebener Knoten aktiviert einige dieser Listener und andere nicht, und der Betreiber kann diese Menge ändern, ohne die Softwareversion anzutasten. Zwei Knoten auf demselben Build verhalten sich daher unterschiedlich, und ein Profil, das gegen den einen funktioniert, beweist nichts über das nächste Ziel. Die eigene Liste des Knotens hat bei der Wahl des Verbindungsziels mehr Gewicht als die Projektseite.

Lesen Sie die Liste als fünf Felder, nicht als Menü: Endpunkt, Port, Transport, Protokollfamilie und Authentifizierungsmethode. Ein öffentlicher Knoten, der SSTP bewirbt, hat Ihnen von einem Listener auf einem Port erzählt; er hat Ihnen nicht gesagt, welches Zertifikat er vorlegt oder ob Ihr Konto dort funktioniert. Der Abgleich dieser fünf Felder mit Ihrem Profil ist schneller als jede noch so gründliche Neuinstallation des Clients und liefert eine schriftliche Erwartung, die Sie später testen können.

Bringen Sie das Profil mit dem genannten Endpunkt in Einklang

Ein nativer SoftEther-Eintrag ist nicht automatisch eine OpenVPN-Konfiguration, auch wenn beide auf einer Anbieterseite unter einer Überschrift erscheinen. Wenn ein Knoten sowohl einen TCP- als auch einen UDP-Listener für OpenVPN veröffentlicht, behandeln Sie sie als zwei Endpunkte: Ein von einem auf den anderen geändertes Profil zeigt auf einen Listener, den niemand aktiviert hat. Das Transport-Label in der Datei ist Teil der Adresse, keine kosmetische Einstellung.

Dass der Client eine importierte Datei akzeptiert, belegt, dass die Datei sich parsen lässt. Es sagt nichts darüber, ob am anderen Ende ein entfernter Listener wartet, weshalb der erste Verbindungsversuch der eigentliche Test ist. Vergleichen Sie die Remote-Zeile des Profils mit dem angekündigten Host und Port des Knotens, bevor Sie das Protokoll beschuldigen.

Prüfen Sie die Stufe, die scheitert

Ein Host, der Webverkehr beantwortet, kann trotzdem den vorgesehenen VPN-Dienst nicht anbieten, und ein Host, der ein Protokoll verweigert, ist nicht zwangsläufig für alle ausgefallen. Diese beiden Fehler schicken Menschen am selben Nachmittag in entgegengesetzte Richtungen. Der eine jagt einer Firewall hinterher, die in Ordnung ist; der andere installiert einen Client neu, der nie das Problem war. Prüfen Sie jeden Pfad getrennt, damit die Antwort einen Listener beschreibt und nicht den ganzen Host.

Diese fünf Prüfungen decken die gängigen Methoden öffentlicher Knoten ab. Führen Sie sie aus demselben Netz aus, das der Client verwendet, denn ein gefilterter Port sieht aus der Ferne genauso aus wie ein fehlender Listener.

nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example

Ordnen Sie jeden beobachteten Fehler seiner Zeile zu, bevor Sie etwas ändern. Ein TLS-Identitätsfehler beweist, dass der Listener existiert, also würde das Umschreiben des Profils auf ein anderes Protokoll funktionierende Belege verwerfen. Eine abgelehnte Verbindung beweist nur, dass dieser Port nicht geantwortet hat, was eine viel engere Aussage ist als „der Knoten unterstützt kein OpenVPN“.

Bewahren Sie den Fehler auf, bevor Sie etwas ändern

Notieren Sie das genaue Ergebnis: eine Zeitüberschreitung, ein Zertifikats-Identitätsfehler, eine Kontoablehnung und eine Ablehnung auf Anwendungsebene sind vier verschiedene Ausgänge. Nur der erste betrifft ein nicht verfügbares Protokoll, und nur der letzte betrifft eine Berechtigung nach erfolgreicher Verbindung. Das Zurücksetzen des Clients oder der Wechsel des Protokolls zerstört diese Unterscheidung, weil der nächste Fehler mit einer anderen Vorgeschichte und ohne Vergleichsbasis eintrifft.

Schwächen Sie die Prüfung nicht ab, damit ein inkompatibles Profil zu funktionieren scheint. Eine deaktivierte Zertifikatsprüfung verwandelt einen klaren Identitätsfehler in eine Verbindung zu etwas, das Sie nicht erreichen wollten, und der daraus folgende Erfolg ist schlimmer als der ursprüngliche Fehler, weil er verbirgt, welche Stufe falsch war.

Prüfen Sie pro Knoten erneut, jedes Mal

Die nativen Optionen SSL, OpenVPN, L2TP/IPsec und SSTP in einer Liste öffentlicher Knoten beschreiben die Konfiguration dieses Knotens in jenem Moment. Dieselbe Software kann anderswo ein anderes Set anbieten, und ein Anbieter kann einen Listener zwischen Ihrem Lesezeichen und Ihrem nächsten Versuch zurückziehen. Alte Notizen beschreiben alte Bereitstellungen.

Halten Sie das geprüfte Profil mit seinem Endpunkt und seiner Methode fest und wiederholen Sie die Prüfung, wenn sich der Knoten ändert oder die Verbindung zu scheitern beginnt. Die SoftEther-Protokollspezifikation ist die Referenz dafür, wozu die Software fähig ist; die eigene Liste des Knotens ist die Referenz dafür, was er tut. Halten Sie beide Dokumente getrennt, und die Diagnose wird kürzer.