Cliente de SoftEther al arrancar: AccountStartupSet y el orden del demonio

Reiniciar la máquina la deja en la red con el túnel caído otra vez. El cliente de SoftEther guarda dos estados que casi todo el mundo trata como uno: si el servicio se está ejecutando y si a una cuenta guardada se le permite subir con él. Ambos deben ser ciertos, y el segundo es una marca por cuenta, no un ajuste de arranque. Ejecute las cuatro comprobaciones siguientes en orden y deténgase en el primer fallo.

Confirme que la cuenta está marcada para el inicio automático

La marca vive en el registro de la cuenta dentro de la propia configuración del cliente, así que reinstalar el cliente o restaurar un directorio vacío la borra. Abra la consola de administración y mire la lista de cuentas antes de cambiar cualquier otra cosa.

cd /opt/softether/vpnclient
./vpncmd

Seleccione 2 para la administración del cliente VPN y acepte el servidor local pulsando Enter.

AccountStartupSet
office-hub
exit

AccountStartupSet registra la cuenta como una que debe subir cuando arranca el servicio del cliente. No inicia el servicio ni crea una cuenta nueva, y no imprime nada útil cuando el nombre es incorrecto. Vuelva a leer la lista de cuentas después del comando, porque un error de tecleo es silencioso y se parece exactamente a una marca que no surtió efecto.

Confirme que el servicio arranca, y lo bastante pronto

En Linux el cliente se ejecuta como demonio desde su propio directorio, y tiene que estar arriba antes de que cualquier paso de arranque intente usar la cuenta. Un gancho corto que cambie de directorio y lo inicie basta en sistemas que aún ejecutan rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Donde rc.local ya no existe, escriba una unidad de systemd con un WorkingDirectory explícito y una política de reinicio. El binario resuelve su configuración en relación con el lugar desde el que se inicia, así que una unidad sin ese ajuste puede arrancar con éxito y no leer nada. El orden es la segunda mitad del problema: un intento de conexión que se ejecuta antes de que el demonio escuche falla de forma intermitente, algo mucho más difícil de diagnosticar que un fallo constante. Una política de reinicio cubre el tercer caso, cuando el demonio muere en silencio horas después.

Revise la lista de procesos en lugar de fiarse de un archivo pid dejado por el arranque anterior.

Confirme que el adaptador ha recibido una dirección

Cuando la cuenta se conecta, el cliente presenta un adaptador virtual y el adaptador aún necesita una dirección. Un concentrador con SecureNAT suele responder al DHCP; un concentrador puenteado a una LAN física espera que, en su lugar, responda el servidor de esa LAN.

ip -brief address
dhclient vpn_vpn1

Tome el nombre de la interfaz del listado, porque el número de un ejemplo no es una constante. Si la dirección debe ser estática, póngala en la configuración de red de la distribución para esa interfaz, de modo que se vuelva a aplicar tras un evento de enlace y no solo al arrancar. Un script de una sola ejecución deja el adaptador sin dirección la primera vez que el túnel se reconecta durante el día. Ese fallo parece un túnel muerto aunque la cuenta esté bien.

Un adaptador sin dirección es el fallo más silencioso de la lista, ya que la cuenta sigue informando de que está conectada.

Confirme que la ruta apunta donde usted cree

El tráfico puede seguir fallando con un enlace sano y una dirección válida. Pregunte al núcleo qué interfaz usaría para un destino dentro de la subred del concentrador y luego compare esa respuesta con el túnel.

ip route get 10.10.20.15

Una subred local que se solape con el rango del concentrador gana, porque su ruta es más específica y ya está instalada.

Eso es una decisión de numeración, no un fallo del cliente, y reiniciar el servicio no lo cambiará. La configuración del resolutor es la otra mitad: una dirección sin un servidor DNS que funcione produce un túnel que pasa todas las comprobaciones de enlace y aun así no puede abrir un nombre.

Escriba las cuatro comprobaciones en las notas de reconstrucción

Anote juntos el nombre de la cuenta, el comando de inicio del servicio y el nombre de la interfaz, porque un host reconstruido restaura los datos de la cuenta pero no el gancho del sistema operativo que lanza el demonio. Esos viven en lugares distintos y normalmente los respaldan personas distintas.

La marca es una línea que volver a aplicar y fácil de olvidar.

Mantenga el orden: marca, servicio, dirección, ruta. Una lista de verificación que empiece por la mitad produce muchas respuestas equivocadas y seguras.