Reconectar un cliente OpenVPN: tres controles, tres alcances

Alguien pide que se reconecte el cliente VPN, y esa petición puede significar tres cosas distintas. Puede significar descartar una sesión autenticada, avisar a todos los clientes de que un servidor UDP se marcha o reiniciar el propio demonio. Cada una tiene un radio de impacto distinto, y elegir la incorrecta convierte una reparación para un usuario en una caída. El alcance es la decisión, y el comando se deriva de él.

Pregunte a quién debe afectar antes de preguntar qué control usar.

Una instancia: la interfaz de gestión

Una interfaz de gestión configurada puede listar las instancias conectadas y descartar exactamente una de ellas. Cada sesión lleva un identificador de cliente, y client-kill CID apunta a ese identificador en lugar de a un nombre común. Lea el identificador vivo de la salida de estado actual, porque un valor copiado de un registro antiguo se refiere a una sesión que ya no existe. Descartar la instancia termina esa conexión y nada más.

No garantiza una conexión nueva. Que el cliente vuelva depende de su configuración de reintentos, de sus entradas remotas restantes, de sus requisitos de autenticación y de si la aplicación supervisora sigue en ejecución. Un cliente que vuelve obtiene un identificador nuevo, y por eso comparar identificadores es la única forma fiable de distinguir lo viejo de lo nuevo.

Un aviso de salida UDP no es una orden por cliente

explicit-exit-notify es una directiva de configuración sobre eventos de salida y reinicio. En un cliente UDP indica al par que la sesión termina, y el argumento numérico controla cuántas veces se reintenta el aviso. Cuando el servidor funciona sobre UDP envía un mensaje de control de reinicio a sus clientes conectados, y los valores documentados distinguen reconectar al mismo servidor de pasar a otra entrada remota. Es una señal de ciclo de vida con una audiencia amplia.

Nada en él selecciona un cliente arbitrario en un momento arbitrario. Tratarlo como un botón de reconexión llega a todas las sesiones conectadas a la vez.

Las señales actúan sobre el proceso, no sobre una sesión

SIGUSR1 pide a un proceso en ejecución que reinicie su conexión sin releer la configuración, y las opciones de persistencia deciden qué sobrevive a ese reinicio. SIGHUP va más allá: relee el archivo de configuración y reabre sus recursos. SIGTERM y SIGINT piden un apagado ordenado. Son operaciones a nivel de proceso: en un servidor con varios clientes afectan a cada sesión que el proceso transporta, no a la que aparece en el ticket.

Cuando el proceso se ejecuta bajo un gestor de servicios, use el control propio del gestor en lugar de enviar una señal a un PID que encontró en una lista de procesos. Lea la unidad para ver qué señal envía el gestor, porque un reinicio y una recarga hacen cosas distintas al mismo demonio.

Decida el alcance antes de elegir el control

Tres preguntas lo resuelven. A quién debe afectar: a un usuario, a cada cliente de un servidor o al demonio y todo lo que transporta. Qué debe sobrevivir: la configuración, el estado del túnel o nada. Quién está autorizado: la integración de gestión, el propietario del servicio o el operador de red que controla el aviso de salida. Responda eso y solo encaja un control.

Añadir un escucha de control sin autenticar para obtener un botón de reconexión entrega a quien pueda alcanzar el puerto mucho más que ese botón.

Verifique la sesión nueva, no la desconexión

Un evento de desconexión demuestra que la sesión antigua terminó. No dice nada sobre una nueva que se autentique, reciba una dirección, instale rutas o alcance el recurso que el usuario necesitaba. Compruebe el identificador nuevo, luego el estado del túnel, luego un recurso real. Esos tres pasos son la diferencia entre una reconexión y una conexión que funciona.

Escriba el alcance en el registro de cambios. «Reconecté el cliente» no es una descripción cuando el cliente era uno de cuarenta en un servidor compartido.