Client de SoftEther a l’arrencada: AccountStartupSet i l’ordre del dimoni
El client pot arrencar net i, tot i així, deixar tots els comptes desconnectats. Fixa la marca del compte, arrenca primer el dimoni i després revisa l’adaptador i la ruta.
Reiniciar la màquina la deixa a la xarxa amb el túnel tornat a caure. El client de SoftEther guarda dos estats que la majoria de la gent tracta com un: si el servei s’està executant i si es permet que un compte desat pugi amb ell. Tots dos han de ser certs, i el segon és una marca per compte, no un paràmetre d’arrencada. Feu les quatre comprovacions següents en ordre i atureu-vos al primer error.
Confirmeu que el compte està marcat per a l’inici automàtic
La marca viu al registre del compte dins de la configuració pròpia del client, així que reinstal·lar el client o restaurar un directori buit l’esborra. Obriu la consola de gestió i mireu la llista de comptes abans de canviar res més.
cd /opt/softether/vpnclient
./vpncmd
Seleccioneu 2 per a la gestió del client VPN i accepteu el servidor local prement Enter.
AccountStartupSet
office-hub
exit
AccountStartupSet registra el compte com un que s’ha de pujar quan s’inicia el servei del client. No inicia el servei ni crea un compte nou, i no imprimeix res d’útil quan el nom és incorrecte. Torneu a llegir la llista de comptes després de l’ordre, perquè una errada d’escriptura és silenciosa i sembla exactament una marca que no ha entrat en vigor.
Confirmeu que el servei arrenca, i prou aviat
A Linux el client s’executa com a dimoni des del seu propi directori, i ha d’estar en marxa abans que cap pas d’arrencada intenti fer servir el compte. Un ganxo curt que canvia de directori i l’inicia és suficient en sistemes que encara executin rc.local.
cd /opt/softether/vpnclient
./vpnclient start
On ja no hi ha rc.local, escriviu una unitat de systemd amb un WorkingDirectory explícit i una política de reinici. El binari resol la seva configuració respecte d’on s’inicia, així que una unitat sense aquest paràmetre pot arrencar correctament i no llegir res. L’ordre és la segona meitat del problema: un intent de connexió que s’executa abans que el dimoni estigui escoltant falla de manera intermitent, cosa molt més difícil de diagnosticar que un error constant. Una política de reinici cobreix el tercer cas, quan el dimoni mor en silenci hores després.
Reviseu la llista de processos en lloc de confiar en un fitxer pid deixat per l’arrencada anterior.
Confirmeu que l’adaptador ha rebut una adreça
Quan el compte es connecta, el client presenta un adaptador virtual i l’adaptador encara necessita una adreça. Un concentrador amb SecureNAT normalment respon al DHCP; un concentrador pont amb una LAN física espera que, en canvi, respongui el servidor d’aquesta LAN.
ip -brief address
dhclient vpn_vpn1
Agafeu el nom de la interfície del llistat, perquè el número d’un exemple no és una constant. Si l’adreça ha de ser estàtica, poseu-la a la configuració de xarxa de la distribució per a aquesta interfície perquè es torni a aplicar després d’un esdeveniment d’enllaç i no només a l’arrencada. Un script d’una sola execució deixa l’adaptador sense adreça la primera vegada que el túnel es reconecta durant el dia. Aquest error sembla un túnel mort tot i que el compte està bé.
Un adaptador sense adreça és l’error més silenciós de la llista, ja que el compte encara informa que està connectat.
Confirmeu que la ruta apunta on us penseu
El trànsit encara pot fallar amb un enllaç sa i una adreça vàlida. Pregunteu al nucli quina interfície faria servir per a una destinació dins de la subxarxa del concentrador i compareu després aquesta resposta amb el túnel.
ip route get 10.10.20.15
Una subxarxa local que se solapi amb el rang del concentrador guanya, perquè la seva ruta és més específica i ja està instal·lada.
Això és una decisió de numeració, no un error del client, i reiniciar el servei no ho canviarà. La configuració del resolutor és l’altra meitat: una adreça sense un servidor DNS que funcioni produeix un túnel que passa totes les comprovacions d’enllaç i encara no pot obrir cap nom.
Escriviu les quatre comprovacions a les notes de reconstrucció
Anoteu junts el nom del compte, l’ordre d’inici del servei i el nom de la interfície, perquè un amfitrió reconstruït restaura les dades del compte però no el ganxo del sistema operatiu que llança el dimoni. Aquests viuen en llocs diferents i normalment els fan còpies de seguretat persones diferents.
La marca és una línia per tornar a aplicar i fàcil d’oblidar.
Mantingueu l’ordre: marca, servei, adreça, ruta. Una llista de verificació que comença pel mig produeix moltes respostes errònies plenes de confiança.