RemoteEnable ist kein VPN-Login: SoftEther-Verwaltung abgrenzen

Die Anleitung sagt, man solle RemoteEnable ausführen und dann verbinden, und das liest sich, als wären diese beiden Schritte dieselbe Art von Sache. Sind sie nicht. RemoteEnable erteilt einem anderen Rechner die Berechtigung, den auf diesem Computer laufenden SoftEther VPN-Clientdienst zu verwalten. Verbinden ist ein VPN-Konto, das sich gegenüber einem Server authentifiziert, und daran ist überhaupt keine Verwaltungsberechtigung beteiligt.

Der Mythos: RemoteEnable schaltet das VPN ein

Die Verwirrung entsteht aus der Nachbarschaft. Eine Anleitung aktiviert die Fernverwaltung, startet den Clientdienst neu, verbindet sich dann, und die Verbindung funktioniert anschließend, sodass die beiden Schritte kausal verknüpft wirken. Was sich tatsächlich geändert hat, ist, wer mit dem Dienst sprechen darf, nicht ob der Dienst einen Server erreichen kann. Deaktivieren Sie die Fernverwaltung auf einem korrekt konfigurierten Client, und die VPN-Verbindung kommt trotzdem zustande.

Die Befehlshilfe im Upstream-Projekt ist eindeutig zum Umfang: Fernverwaltung über VPN Client Manager oder vpncmd von außerhalb von localhost. Nichts in dieser Beschreibung erwähnt einen Tunnel, ein Konto oder eine Route. Die erteilte Berechtigung ist administrative Reichweite, und ihr Gegenstand ist der Clientdienst, nicht die Verbindung.

Drei Identitäten, die sich das Wort Passwort teilen

Alte Anleitungen verwenden ein Wort für drei unzusammenhängende Anmeldeinformationen, und so landen Bereitstellungen mit einem Geheimnis im falschen Feld.

Das Verwaltungspasswort des Clientdienstes schützt die Administration des lokalen SoftEther-Clients. Das VPN-Kontopasswort authentifiziert sich gegenüber einem Server nach dessen Richtlinie. Das Serverzertifikat ist überhaupt kein Passwort, aber es beantwortet, welchen Endpunkt der Client akzeptieren soll. Eines davon zu ändern ändert die anderen nicht, und einen Wert zwischen ihnen zu kopieren ergibt eine andere Konfiguration statt einer einfacheren.

Die Option nur-fern beim Verwaltungspasswort verdient einen zweiten Blick, denn sie entscheidet, ob die Passwortpflicht auch für die Verwaltung vom lokalen Rechner gilt. Diesen Umfang zu verengen ist eine bewusste Wahl für einen Einzelplatz-Laptop, kein Ausweg für ein Passwort, das niemand notiert hat.

Was das Aktivieren der Fernverwaltung tatsächlich ändert

Zwei betriebliche Folgen ergeben sich, und beide werden in einer Copy-and-paste-Anleitung leicht übersehen. Ein Verwaltungspasswort wird obligatorisch, sobald die Fernverwaltung eingeschaltet ist, und die neue Verfügbarkeit greift erst, nachdem der Clientdienst neu gestartet wurde.

Dieser Neustart ist eine echte Unterbrechung für alles, was den Client nutzt, also planen Sie ihn mit demjenigen, dem der Rechner gehört. Das Aktivieren der Funktion öffnet auch nicht von selbst einen Weg durch die Firewall: Der Dienst muss von der Verwaltungsstation aus erreichbar bleiben, und eine Host-Firewall oder eine ACL weiter oben kann ihn unerreichbar halten. Ein unerreichbarer Dienst ist kein Beweis, dass die Berechtigung richtig abgegrenzt wurde, sondern nur, dass etwas anderes ihn blockiert.

Schreiben Sie den vorgesehenen Verwaltungsweg in die Bereitstellungsnotizen, einschließlich des Ports und des Adressbereichs, der ihn nutzen darf. Diese Notiz ist auch der Ort, um festzuhalten, wer die Fähigkeit angefordert hat und wann sie zurückgezogen werden soll.

Entscheiden Sie, wer diesen Client verwalten darf

Auf einem Laptop, der Ihnen gehört, bleibt die Administration an der lokalen Konsole, es sei denn, Sie können den Rechner benennen, der Fernzugriff braucht, und sagen, warum. Bei einem zentral verwalteten Gerät benennen Sie den Administrator, den Verwaltungsweg und den Wiederherstellungsverantwortlichen, bevor Sie irgendetwas aktivieren. Die Frage ist nicht, ob die Funktion bequem ist, sondern wer für die Konfiguration rechenschaftspflichtig ist, die sie freilegt.

Führen Sie die Befehle gegen den lokalen Dienst aus, damit die Änderung in Ihrer eigenen Shell-Historie landet und nicht auf einem Screenshot: vpncmd localhost /client /cmd RemoteDisable schaltet die Fähigkeit aus, und derselbe Befehl mit RemoteEnable schaltet sie ein. Starten Sie den Dienst danach neu, sonst ist die Einstellung nicht wirksam.

Wenn eine Anleitung sie als vorbereitenden Schritt ohne Erklärung aktiviert, behandeln Sie das als offene Frage und nicht als Anweisung, der zu folgen ist. Fragen Sie, welche Verwaltungsstation sie nutzen soll, und wenn es keine Antwort gibt, lassen Sie die Fähigkeit deaktiviert.

Prüfen Sie Verwaltungszugriff und Konnektivität getrennt

Zwei Tests beantworten zwei verschiedene Fragen, und nur einen davon auszuführen ist der Weg, wie eine Bereitstellung bei einer Fernadministration endet, die niemand beabsichtigt hat.

vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList

Die ersten beiden Zeilen stellen den Client wieder unter lokale Administration und wenden die Änderung an. Die letzten beiden bestätigen, dass die VPN-Konten und virtuellen Adapter weiterhin konfiguriert sind, was sie sein sollten, denn Verwaltungsumfang und Verbindungszustand sind unabhängige Einstellungen. Wenn die Kontoliste nach dem Neustart leer zurückkommt, ist etwas anderes kaputtgegangen, und die Einstellung für die Fernverwaltung ist nicht die Erklärung.

Testen Sie dann die Verbindung selbst vom Client aus und bestätigen Sie, dass der Adapter die erwartete Adresse und die erwarteten Routen hält. Eine erfolgreiche vpncmd-Sitzung beweist eine Steuerbeziehung und sagt nichts darüber aus, ob Verkehr durch den Tunnel verlässt.