Client SoftEther au démarrage : AccountStartupSet et l’ordre du démon

Redémarrer la machine la laisse sur le réseau avec le tunnel de nouveau tombé. Le client SoftEther garde deux états que la plupart des gens traitent comme un seul : si le service tourne, et si un compte enregistré est autorisé à monter avec lui. Les deux doivent être vrais, et le second est un indicateur par compte plutôt qu’un réglage de démarrage. Exécutez les quatre vérifications ci-dessous dans l’ordre et arrêtez-vous au premier échec.

Confirmez que le compte est marqué pour un démarrage automatique

L’indicateur vit dans l’enregistrement du compte au sein de la configuration propre au client, donc réinstaller le client ou restaurer un répertoire vide l’efface. Ouvrez la console de gestion et regardez la liste des comptes avant de changer quoi que ce soit d’autre.

cd /opt/softether/vpnclient
./vpncmd

Choisissez 2 pour la gestion du client VPN et acceptez le serveur local en appuyant sur Entrée.

AccountStartupSet
office-hub
exit

AccountStartupSet enregistre le compte comme devant être monté au démarrage du service client. Il ne lance pas le service et ne crée pas de nouveau compte, et il n’affiche rien d’utile quand le nom est faux. Relisez la liste des comptes après la commande, car une faute de frappe est silencieuse et ressemble exactement à un indicateur qui n’a pas pris effet.

Confirmez que le service démarre, et assez tôt

Sous Linux, le client tourne comme un démon depuis son propre répertoire, et il doit être actif avant que toute étape de démarrage n’essaie d’utiliser le compte. Un court crochet qui change de répertoire et le lance suffit sur les systèmes qui exécutent encore rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Là où rc.local a disparu, écrivez une unité systemd avec un WorkingDirectory explicite et une politique de redémarrage. Le binaire résout sa configuration par rapport à l’endroit d’où il est lancé, donc une unité sans ce réglage peut démarrer avec succès et ne rien lire. L’ordre est la seconde moitié du problème : une tentative de connexion qui s’exécute avant que le démon n’écoute échoue par intermittence, ce qui est bien plus difficile à diagnostiquer qu’un échec constant. Une politique de redémarrage couvre le troisième cas, où le démon meurt silencieusement des heures plus tard.

Vérifiez la liste des processus plutôt que de faire confiance à un fichier pid laissé par le démarrage précédent.

Confirmez que l’adaptateur a reçu une adresse

Une fois le compte connecté, le client présente un adaptateur virtuel et l’adaptateur a encore besoin d’une adresse. Un concentrateur avec SecureNAT répond généralement au DHCP ; un concentrateur ponté sur un LAN physique attend que, à la place, le serveur de ce LAN réponde.

ip -brief address
dhclient vpn_vpn1

Prenez le nom de l’interface dans la liste, car le nombre d’un exemple n’est pas une constante. Si l’adresse doit être statique, mettez-la dans la configuration réseau de la distribution pour cette interface, afin qu’elle soit réappliquée après un événement de lien et pas seulement au démarrage. Un script à usage unique laisse l’adaptateur sans adresse la première fois que le tunnel se reconnecte dans la journée. Cet échec ressemble à un tunnel mort alors que le compte est correct.

Un adaptateur sans adresse est l’échec le plus silencieux de la liste, car le compte signale toujours être connecté.

Confirmez que la route pointe là où vous croyez

Le trafic peut encore échouer avec un lien sain et une adresse valide. Demandez au noyau quelle interface il utiliserait pour une destination dans le sous-réseau du concentrateur, puis comparez cette réponse avec le tunnel.

ip route get 10.10.20.15

Un sous-réseau local qui chevauche la plage du concentrateur gagne, car sa route est plus spécifique et déjà installée.

C’est une décision de numérotation plutôt qu’un bug du client, et redémarrer le service n’y changera rien. La configuration du résolveur est l’autre moitié : une adresse sans serveur DNS fonctionnel produit un tunnel qui passe toutes les vérifications de lien et ne peut toujours pas ouvrir un nom.

Écrivez les quatre vérifications dans les notes de reconstruction

Notez ensemble le nom du compte, la commande de démarrage du service et le nom de l’interface, car un hôte reconstruit restaure les données du compte mais pas le crochet du système d’exploitation qui lance le démon. Ceux-ci vivent à des endroits différents et sont généralement sauvegardés par des personnes différentes.

L’indicateur est une ligne à réappliquer et facile à oublier.

Gardez l’ordre : indicateur, service, adresse, route. Une liste de contrôle qui commence au milieu produit beaucoup de réponses fausses et assurées.