SoftEther-Client beim Start: AccountStartupSet und die Reihenfolge des Daemons

Der Client kann sauber starten und trotzdem jedes Konto getrennt lassen. Setzen Sie das Konto-Flag, starten Sie zuerst den Daemon und prüfen Sie dann Adapter und Route.

Ein Neustart des Rechners lässt ihn mit wieder abgebautem Tunnel im Netz. Der SoftEther-Client hält zwei Zustände, die die meisten für einen halten: ob der Dienst läuft und ob ein gespeichertes Konto mit ihm hochkommen darf. Beides muss zutreffen, und das Zweite ist ein Flag pro Konto und keine Starteinstellung. Führen Sie die vier Prüfungen unten der Reihe nach aus und halten Sie beim ersten Fehler an.

Bestätigen Sie, dass das Konto für den automatischen Start markiert ist

Das Flag lebt im Kontoeintrag innerhalb der eigenen Konfiguration des Clients, daher löscht eine Neuinstallation des Clients oder das Wiederherstellen eines leeren Verzeichnisses es. Öffnen Sie die Verwaltungskonsole und sehen Sie sich die Kontoliste an, bevor Sie etwas anderes ändern.

cd /opt/softether/vpnclient
./vpncmd

Wählen Sie 2 für die VPN-Client-Verwaltung und bestätigen Sie den lokalen Server mit der Eingabetaste.

AccountStartupSet
office-hub
exit

AccountStartupSet vermerkt das Konto als eines, das beim Start des Clientdienstes hochgebracht werden soll. Es startet weder den Dienst noch legt es ein neues Konto an, und es gibt nichts Nützliches aus, wenn der Name falsch ist. Lesen Sie die Kontoliste nach dem Befehl erneut, denn ein Tippfehler ist still und sieht genau wie ein Flag aus, das nicht wirksam wurde.

Bestätigen Sie, dass der Dienst startet, und früh genug

Unter Linux läuft der Client als Daemon aus seinem eigenen Verzeichnis, und er muss laufen, bevor irgendein Startschritt das Konto zu nutzen versucht. Ein kurzer Hook, der das Verzeichnis wechselt und ihn startet, genügt auf Systemen, die noch rc.local ausführen.

cd /opt/softether/vpnclient
./vpnclient start

Wo rc.local fehlt, schreiben Sie eine systemd-Unit mit explizitem WorkingDirectory und einer Neustartrichtlinie. Die Binärdatei löst ihre Konfiguration relativ zum Startort auf, daher kann eine Unit ohne diese Einstellung erfolgreich starten und nichts lesen. Die Reihenfolge ist die zweite Hälfte des Problems: Ein Verbindungsversuch, der läuft, bevor der Daemon lauscht, schlägt sporadisch fehl, was viel schwerer zu diagnostizieren ist als ein gleichbleibender Fehler. Eine Neustartrichtlinie deckt den dritten Fall ab, in dem der Daemon Stunden später still stirbt.

Prüfen Sie die Prozessliste, statt einer pid-Datei zu vertrauen, die der vorherige Start hinterlassen hat.

Bestätigen Sie, dass der Adapter eine Adresse erhalten hat

Sobald das Konto verbindet, stellt der Client einen virtuellen Adapter bereit, und der Adapter braucht noch eine Adresse. Ein Hub mit SecureNAT beantwortet normalerweise DHCP; ein an ein physisches LAN gebrückter Hub erwartet stattdessen, dass der Server dieses LANs antwortet.

ip -brief address
dhclient vpn_vpn1

Nehmen Sie den Schnittstellennamen aus der Auflistung, denn die Nummer in einem Beispiel ist keine Konstante. Wenn die Adresse statisch sein muss, legen Sie sie in der Netzwerkkonfiguration der Distribution für diese Schnittstelle ab, damit sie nach einem Link-Ereignis erneut angewendet wird und nicht nur beim Start. Ein Einmalskript lässt den Adapter adresslos, wenn der Tunnel im Tagesverlauf das erste Mal erneut verbindet. Dieser Fehler sieht wie ein toter Tunnel aus, obwohl das Konto in Ordnung ist.

Ein Adapter ohne Adresse ist der leiseste Fehler in der Liste, denn das Konto meldet weiterhin verbunden.

Bestätigen Sie, dass die Route dorthin zeigt, wo Sie denken

Der Verkehr kann auch bei gesunder Verbindung und gültiger Adresse fehlschlagen. Fragen Sie den Kernel, welche Schnittstelle er für ein Ziel im Hub-Subnetz verwenden würde, und vergleichen Sie diese Antwort dann mit dem Tunnel.

ip route get 10.10.20.15

Ein lokales Subnetz, das den Hub-Bereich überlappt, gewinnt, weil seine Route spezifischer und bereits installiert ist.

Das ist eine Nummerierungsentscheidung und kein Clientfehler, und ein Neustart des Dienstes ändert daran nichts. Die Resolver-Konfiguration ist die andere Hälfte: Eine Adresse ohne funktionierenden DNS-Server erzeugt einen Tunnel, der jede Link-Prüfung besteht und trotzdem keinen Namen öffnen kann.

Schreiben Sie die vier Prüfungen in die Wiederaufbau-Notizen

Halten Sie Kontoname, Startbefehl des Dienstes und Schnittstellennamen zusammen fest, denn ein neu aufgebauter Host stellt die Kontodaten wieder her, aber nicht den Betriebssystem-Hook, der den Daemon startet. Diese liegen an verschiedenen Orten und werden üblicherweise von verschiedenen Personen gesichert.

Das Flag ist eine Zeile zum erneuten Anwenden und leicht zu vergessen.

Halten Sie die Reihenfolge ein: Flag, Dienst, Adresse, Route. Eine Checkliste, die in der Mitte beginnt, liefert viele selbstsichere falsche Antworten.

Ähnliche Artikel