SoftEther-Verbindungsprofil: sechs Felder vor dem Import prüfen

Der Import des Profils gelingt, doch die Authentifizierung scheitert, weil die Datei auf einen Virtual Hub zeigt, dem das Konto nie beigetreten ist. An der Datei ist nichts fehlerhaft; sie beschreibt eine Konstellation, für die die Zugangsdaten nicht ausgestellt wurden. Sechs Felder entscheiden, ob der Import funktionieren kann: Hostname, Port, Protokoll, Virtual Hub, Benutzeridentität und ob Ihnen jemand versehentlich Administrator-Zugangsdaten gegeben hat. Prüfung eins bis drei deckt diese Felder der Reihe nach ab, und die letzten beiden betreffen die Datei selbst und das, womit Sie sich tatsächlich verbunden haben.

Prüfung 1: Hostname und Port

Lesen Sie Hostname, Port und die angegebene Zugriffsmethode, bevor Sie irgendetwas importieren. Der native SoftEther-Listener antwortet normalerweise auf TCP 443, mit 992 und 5555 als Alternativen, die Betreiber für Clients hinter restriktiven Netzen freischalten. Ein Profil, das auf einen Port zielt, der eine Website oder einen anderen Dienst bereitstellt, scheitert vor der Authentifizierung und meldet den Fehler als Zugangsdatenproblem. Vergleichen Sie das Paar mit dem, was der Betreiber für diesen Endpunkt veröffentlicht, nicht mit einem Verzeichniseintrag, den jemand letztes Jahr zusammengetragen hat. Wenn der Hostname auf eine Adresse auflöst, die der Betreiber nie erwähnt, hören Sie dort auf, denn der nächste Schritt sendet Zugangsdaten an diese Adresse.

Port 443 ist gemeinsames Terrain, daher beweist der Port allein nichts über den Dienst dahinter. Ein SoftEther-Client trennt beides über den Protokoll-Handshake, weshalb ein Profil auf den richtigen Port zeigen und trotzdem an einem Webserver enden kann. Dieser Fehler sieht im Client-Log wie ein falsches Passwort aus, obwohl nie ein Passwort geprüft wurde.

Notieren Sie den Endpunkt als Hostname, Port und Methode, in dieser Reihenfolge. Dieses Tripel ist der Teil, den Sie ohne Verbindung prüfen können, und es ist der Teil, den Sie zitieren, wenn Sie den Betreiber fragen, ob der Listener noch läuft. Alles, was Sie nicht aus einer veröffentlichten Quelle ergänzen können, bleibt ungeprüft statt angenommen.

Prüfung 2: Das Protokoll bestimmt den Client

Ein Server, der mehrere Zugriffsmethoden anbietet, macht aus einer exportierten Datei kein Profil, das jeder Client öffnen kann. Each method has its own format, its own client and its own failure mode, und das Mischen erzeugt Fehler, die wie Zugangsdatenprobleme klingen. Entscheiden Sie, welche Methode die Datei angibt, bevor Sie entscheiden, welcher Client sie öffnet.

Die folgende Tabelle listet die üblichen Ports und was die jeweilige Methode tatsächlich benötigt. Ports sind die Wahl des Betreibers, behandeln Sie sie also als Vorgaben und nicht als Fakten über einen bestimmten Server. Ein natives SoftEther-Profil wird vom SoftEther-Client importiert, ein ovpn-Bundle gehört zu OpenVPN, und SSTP- oder L2TP-Profile werden vom Betriebssystem selbst verarbeitet. Einen zweiten Client zu installieren, um eine Datei zu öffnen, die der erste ablehnt, verwandelt einen klaren Fehler meist in einen verwirrenden.

Lesen Sie die Deklaration in der Datei statt die Dateiendung. Eine Datei, die nach OpenVPN benannt ist, ist per Definition ein OpenVPN-Profil, während ein SoftEther-Profil eine kleine Konfiguration ist, die der SoftEther-Client importiert; die beiden sind nicht austauschbar. Wenn die angegebene Methode eine ist, die Sie nicht bedienen können, beantwortet das die Importfrage.

Prüfung 3: Der Hub, der Benutzer und die Administratorrolle

Für den nativen Zugang nennt das Profil einen Virtual Hub und einen Benutzer darin. A hub is a logical VPN server instance with its own users and its own settings, und der Benutzer ist Mitglied dieses Hubs mit eigener Authentifizierung. Keines von beiden ist Serveradministration, die Listener, Hubs und jeden Benutzer der Bereitstellung kontrolliert. Ein Client-Profil sollte niemals mit dieser Kontrolle daran ankommen. Wenn Ihnen jemand Administrator-Zugangsdaten schickt, damit ein Client funktioniert, ist die Konstellation falsch, ob sie sich verbindet oder nicht.

Halten Sie die drei getrennt, wenn Sie die Verbindung dokumentieren, weil sie sich unterschiedlich widerrufen lassen. Das Entfernen eines Hub-Benutzers beendet den Zugang einer Person und lässt den Rest der Bereitstellung unberührt, während das Rotieren der Administrator-Zugangsdaten alles betrifft. Dieser Unterschied ist auch der Grund, sich gegen einen gemeinsamen Hub-Benutzer für ein Team zu wehren, denn ein einziger Zugang bedeutet ein einziges Widerrufsereignis für alle.

Prüfung 4: Die Datei ist so sensibel wie ihr Inhalt

Je nach Format kann ein Profil ein gespeichertes Passwort, ein Zertifikat oder einen vorab geteilten Schlüssel enthalten. Behandeln Sie den Export als Geheimnis, solange er existiert, denn die Kopie, die Sie an ein Ticket anhängen, ist eine Kopie, die jemand anderes importieren kann. Entfernen Sie die Zugangsdaten vor dem Teilen oder teilen Sie ein neu erzeugtes Profil mit einem frischen Geheimnis. Die Sensibilität der Datei kommt aus ihrem Inhalt, nicht aus ihrer Endung oder Größe.

Bestätigen Sie den Endpunkt über einen Kanal, den der Betreiber veröffentlicht, und behandeln Sie ein Verzeichnisetikett als ungeprüft. Eine Länderflagge und ein Hostname in einer öffentlichen Knotenliste werden von dem gewählt, der den Eintrag eingereicht hat, daher belegt keines von beiden, wer den Server betreibt. Wenn das Profil aus einem öffentlichen Verzeichnis stammt, ist das ein Grund für mehr Prüfungen statt weniger.

Halten Sie fest, woher die Datei kam und wann Sie sie erhielten. Wenn sich eine Verbindung später anders verhält, ist die Herkunft das Erste, was Sie mit dem geprüften Endpunkt vergleichen. Ein Profil ohne Herkunft ist ein Profil, das Sie nicht prüfen können.

Archivieren Sie die Kopie, die Sie geprüft haben, nicht die, die Sie später gefunden haben. Zwei Dateien mit demselben Namen und unterschiedlichen Endpunkten sind der Weg, wie aus einem funktionierenden Import ein Supportfall wird. Bewahren Sie die geprüfte Kopie neben der Notiz über ihre Herkunft auf.

Prüfung 5: Testen Sie die Anwendung, nicht die Statusleuchte

Testen Sie nach dem Import die Anwendung, die Sie tatsächlich brauchen, statt die Verbindungsanzeige. Eine erfolgreiche Authentifizierung belegt, dass die Zugangsdaten funktionieren, nicht dass die erwarteten Routen oder der DNS mit der Sitzung kamen. Verbinden Sie, und nutzen Sie dann den Dienst, den das Profil erreichen sollte.

Prüfen Sie die zugewiesenen Routen und die DNS-Server und notieren Sie, welche Ziele den Tunnel umgehen, wenn das Design eine Aufteilung hat. Wiederholen Sie dann mit einem Ziel, das ausgeschlossen sein sollte, denn ein Split-Tunnel, der alles durch den Tunnel schickt, besteht einen Test mit einem einzigen Ziel in jedem Fall. Wenn eine private Ressource scheitert, ist die Route der Verdächtige vor den Zugangsdaten. Schreiben Sie die vier Ergebnisse auf: authentifiziert, Dienst erreichbar, Routen wie erwartet, ausgeschlossenes Ziel ausgeschlossen.

Vergleichen Sie alle vier Ergebnisse mit dem, was der Betreiber für diesen Hub versprochen hat. Eine Sitzung, die sich authentifiziert, während das ausgeschlossene Ziel ebenfalls erreichbar ist, bedeutet, dass die Aufteilung nicht greift und das Profil nicht das Problem ist. Korrigieren Sie die Erwartung oder die Hub-Richtlinie und führen Sie die vier Prüfungen dann in derselben Reihenfolge erneut aus.