Access Server perdió su enlace tras renombrar una interfaz de red: arregle las claves

Ha renombrado una interfaz de red, o ha restaurado una máquina cuyo adaptador volvió con otro nombre, y ahora el demonio de OpenVPN Access Server no arranca. La interfaz web puede seguir respondiendo o no, según qué componente estuviera vinculado al nombre antiguo. El servicio no está corrupto y la configuración no se ha perdido; un ajuste sigue apuntando a una interfaz que el host ya no tiene.

El reflejo es reinstalar, reinicializar o editar la base de datos hasta que el error desaparezca. Cada una es un cambio mayor que la avería, y la última puede borrar los usuarios, permisos y dependencias que hacían que el servidor mereciera recuperarse. Es un problema de enlace y tiene una solución concreta.

Qué le dice realmente el síntoma

Un demonio que no puede enlazar suele decirlo en su propio registro: la dirección no está disponible o la interfaz no existe. El mensaje es concreto: nombra la dirección que intentó el demonio; compárela con ip -br addr en el host para saber si la interfaz se renombró, se eliminó o se levantó sin su dirección antigua.

Mantenga abierta una consola de recuperación autorizada todo el tiempo. Si el enlace que va a cambiar lleva su única sesión administrativa, se ha cortado la vuelta. Una consola local, una segunda dirección de gestión o una ruta fuera de banda documentada hacen el cambio reversible.

Consulte la configuración antes de editarla

Access Server expone su configuración mediante su propia CLI. La vista documentada es:

sacli ConfigQuery

Ejecútelo en el entorno administrativo documentado para su versión, no desde un shell ajeno en otro host. Guarde los valores actuales en un lugar protegido antes de cambiar nada y no pegue la salida completa en un hilo público de soporte.

Esa salida es una vista de la configuración del servidor, no una copia completa. Las propiedades de usuarios y grupos se consultan por separado, así que un enlace limpio no restaura identidades, y una identidad restaurada no arregla un oyente. Registre ambas como dos artefactos separados.

Determine qué oyente está roto

Access Server ejecuta más de un oyente. Los demonios de OpenVPN llevan el tráfico del túnel, el servicio web lleva el portal de administración y de clientes, y otros componentes pueden tener sus propios puertos. Una petición fallida del navegador no dice cuál falló, ni el número de puerto del mensaje de error.

Las claves de enlace del demonio están documentadas por demonio, y en el tutorial oficial el valor es el identificador de la interfaz aunque los nombres de las claves terminen en ip_address. Lea esa frase dos veces. El tutorial también espera que los demonios UDP y TCP compartan una interfaz, así que corregir solo una clave es una reparación parcial.

Cambie el ajuste nombrado, no las filas coincidentes

El tutorial documenta ConfigPut sobre claves concretas, como vpn.daemon.0.server.ip_address y vpn.daemon.0.listen.ip_address. Use el método propio del producto con el nombre de la clave y el valor nuevo, en la sintaxis que documenta su versión, y cambie solo las claves del oyente que diagnosticó.

Lo que no debe hacer es buscar en la base de datos todas las filas cuyo valor sea el nombre antiguo de la interfaz y reemplazarlas todas. Eso supone que el nombre antiguo solo aparecía en ajustes del oyente, algo que el esquema no promete. También hace imposible revisar el cambio.

Conviene rechazar dos tentaciones más. Restaurar un valor por defecto que escucha en todas las interfaces es una decisión de exposición, no una corrección ortográfica; el enlace local previsto, la ruta publicada y el filtrado delante deben concordar con esa elección. Reinicializar la configuración renombra el problema en lugar de resolverlo, porque una instalación nueva descarta justo los usuarios y permisos que funcionaban antes del cambio.

Aplíquelo y demuestre que la ruta funciona

Corregido el valor, aplíquelo mediante el ciclo de vida documentado del producto ( ciclo de vida ). El tutorial usa sacli start tras fijar las claves; eso no es un reinicio completo del host ni un reinicio de la base de datos.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

Compruebe el oyente, haga una conexión VPN autorizada, alcance un recurso privado y cargue la página administrativa por su ruta esperada. Conserve los permisos y revocaciones existentes; una recuperación que los reinicia ha arreglado el enlace y perdido el despliegue. El trabajo termina cuando el mismo servicio funciona en su interfaz prevista.