OpenVPN Access Server: reiniciar el demonio o aplicar el ajuste

Se pegan dos comandos para lo que parece la misma tarea en OpenVPN Access Server, y hacen cosas distintas. systemctl restart openvpnas detiene y arranca todo el producto. sacli start levanta los servicios internos que leen la configuración que acaba de cambiar. Elegir entre ellos no es cuestión de gusto: depende de lo que diga la documentación del propio ajuste, de si su sesión pasa por el servidor que está a punto de reiniciar y de si siquiera está mirando el producto correcto.

Dos capas, un demonio

Access Server se ejecuta como una sola unidad de systemd, openvpnas, y ese demonio supervisa los servicios internos que hay detrás de la interfaz web y los escuchas de VPN. sacli es la interfaz de línea de comandos hacia la misma instalación, en /usr/local/openvpn_as/scripts/sacli, y puede arrancar, detener y consultar esos componentes internos sin sustituir la unidad.

Por eso existen ambos comandos. Un reinicio del demonio vuelve a ejecutarlo todo, incluido el proceso que termina los túneles de los clientes. sacli start pide al demonio que ya está en marcha que levante sus componentes para que lean la nueva configuración, y eso es lo que realmente requieren la mayoría de los cambios de propiedades.

Condición uno: qué dice la documentación del ajuste

Lea la página del ajuste que cambió, no la de un ajuste que cambió el mes pasado. Una propiedad escrita mediante ConfigPut suele ir seguida de sacli start, y ese par es el paso de aplicación documentado. Un cambio en el comportamiento a nivel de escucha, o cualquier cosa que la página describa como necesitada de reinicio del servicio, es la clase en la que el reinicio de la unidad es correcto.

Los dos comandos no son intercambiables, así que el modo de fallo al adivinar es asimétrico. Usar sacli start cuando hacía falta un reinicio completo deja un proceso viejo sirviendo la configuración anterior, lo que parece que el ajuste se ignoró. Hacer un reinicio completo cuando bastaba sacli start echa a todos los clientes conectados sin motivo.

Condición dos: su propia sesión está dentro del túnel

Si administra Access Server a través de la VPN que proporciona, el reinicio elimina la conexión que lleva su shell. El comando puede completarse después de que muera su sesión, y entonces duda de si funcionó. sacli start también puede interrumpir brevemente una sesión por el mismo motivo cuando el componente que se reinicia maneja su tráfico.

Mantenga abierta una vía fuera de banda antes de cualquiera de los dos comandos: una consola del proveedor, una consola del hipervisor o una sesión serie. Esta condición decide cuándo ejecuta el comando, no cuál ejecuta, y es la que convierte un cambio de dos minutos en un informe de caída.

Condición tres: es este el producto que cree

Access Server no es Community OpenVPN. Una instalación community ejecuta unidades como openvpn@server u openvpn-client@profile, con la configuración en /etc/openvpn, y allí sacli no existe. Reiniciar todas las unidades con openvpn en el nombre en un host compartido es la forma en que túneles no relacionados caen juntos.

Identifique antes de tocar nada: systemctl status openvpnas --no-pager responde si Access Server es lo que se está ejecutando, sacli status lista sus componentes internos y systemctl list-units --type=service lista las unidades cuyos nombres contienen openvpn. Si el último comando muestra unidades con nombres de perfil, está en el producto community y el resto de esto no se le aplica.

Aplíquelo y luego verifique más allá de active

Una unidad que informa active tiene un proceso en marcha, lo que no es lo mismo que una ruta de autenticación que funcione. Tras el paso de aplicación, revise sacli status para los componentes que esperaba reiniciar, confirme que el valor se guardó con sacli ConfigQuery y luego ejecute un inicio de sesión de cliente limitado con una cuenta de prueba.

Termine con algo a nivel de aplicación: llegue a un recurso privado por el túnel, no solo un ping a la dirección pública del servidor. Un handshake que tiene éxito mientras la ruta empujada o el ajuste de DNS son incorrectos pasará todas las comprobaciones del servicio y aun así fallará a la persona que reportó el problema.

el tutorial del proveedor sobre gestión de servicios es la referencia de qué operaciones pertenecen a sacli, y vale la pena abrirla antes de decidir que un reinicio es la opción segura.

La decisión en una pasada

Recorra estas cuatro líneas y deténgase en la primera que encaje:

• La página del ajuste nombra sacli start, o acaba de ejecutar ConfigPut: use sacli start.
• La página exige un reinicio, o el cambio toca escuchas y no propiedades: use systemctl restart openvpnas.
• Su shell llega por este servidor: prepare primero el acceso a la consola y luego ejecute el comando que hayan elegido las dos líneas anteriores.
• Verificación: sacli status, ConfigQuery para el valor, un inicio de sesión, un recurso privado. El estado del servicio por sí solo no es la meta.

Dos de esas líneas son comprobaciones y dos son acciones, y ese es el sentido del orden. Si no puede responder la pregunta sobre el producto, deténgase: el comando que iba a ejecutar pertenece a otra instalación, y el túnel que tumbe no será el que pretendía.