Socket de gestión de OpenVPN: un canal de control, no métricas

Pida un estado a la interfaz de gestión una vez y empieza a parecer un puerto de estado. No lo es. Una vez admitido un cliente, este puede emitir los comandos de control del protocolo, y la cuenta que ejecuta ese cliente hereda todo lo que esos comandos pueden hacerle al demonio. Tratarlo como un flujo de solo lectura es el error que convierte una integración de monitorización en una consola sin autenticación.

La creencia, y lo que cuesta

La creencia es que el oyente de gestión equivale a un punto final de métricas: conecte un recolector, lea los contadores, siga adelante. Lo que ocurre en realidad es que el recolector abre una sesión con capacidades de control, y cualquier otra suposición que haya hecho sobre el despliegue ahora depende de que ese recolector se comporte bien.

Nada en la interfaz anuncia un modo de solo lectura. No hay ningún rol de observador que elegir, y un nombre de usuario en la configuración no crea uno.

Qué tiene realmente un cliente admitido

El demonio de la comunidad acepta un solo cliente de gestión activo a la vez. Ese único espacio significa que una GUI, un script y un agente de monitorización no pueden conectarse todos; el segundo espera o falla mientras el primero mantiene la sesión. Si su diseño asume lectores simultáneos, ya está equivocado.

Donde basta una instantánea periódica, la salida del archivo de estado le da los mismos números sin una sesión activa. Escribir ese archivo a intervalos y leerlo con permisos de archivo ordinarios mantiene al recolector completamente fuera del plano de control, y esa es la disposición que la mayoría de la monitorización necesita de verdad.

Un socket propio, no uno abierto

Un socket de dominio Unix mantiene la ruta de control fuera de la red, lo que elimina del problema la dirección cambiante del túnel. No elimina la cuestión de los permisos. El directorio padre debe ser escribible por la cuenta del servicio y accesible por la cuenta del controlador, y esos son dos permisos separados:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

El archivo de contraseña lleva el secreto de gestión en su primera línea. Proteja ese archivo como cualquier otra credencial y mantenga su contenido fuera de los registros y de los tiques de soporte. Las restricciones de usuario y grupo son comprobaciones de igual en el socket Unix, no permisos del sistema de archivos, así que el proceso previsto necesita tanto el acceso al archivo como la identidad correspondiente.

Hacer que el socket sea accesible para todo el mundo para resolver un error de permisos es el único arreglo que hay que evitar. Convierte un canal de control local en algo que cualquier proceso del host puede manejar.

Publicarlo por TCP no es el mismo diseño

Mover el oyente a un puerto TCP no lo hace más seguro ni más cómodo. La contraseña de gestión se envía en claro, así que un oyente TCP expone tanto la credencial como la sesión a cualquiera que pueda observar la ruta. Llegar a él desde otro host requiere un canal de administración autorizado, o un pequeño agente local que exponga solo las observaciones que necesita.

Una contraseña sobre un transporte en texto claro es autenticación sin confidencialidad, y esa combinación es peor de lo que parece porque se siente protegida.

Dependencias de arranque que no pidió

Varias opciones de gestión cambian el ciclo de vida del demonio. Mantener el arranque hasta que se conecte un controlador, o terminar cuando el controlador desaparece, convierte a un observador opcional en una dependencia dura. Un agente de monitorización que se cayera se llevaría entonces el túnel consigo.

Revise esas opciones antes de habilitar nada más allá del propio socket. La observación opcional debe seguir siendo opcional, y una política de reinicio no debería acoplarse a un recolector añadido para las gráficas.

Un archivo de socket que queda tras un proceso fallido no es prueba de que exista un oyente. Identifique qué instancia posee la ruta antes de eliminarla, y use el flujo de recuperación propio del servicio en lugar de borrar archivos bajo un demonio en ejecución.

Cómo se ve la aceptación

Cuatro comprobaciones cubren el diseño: la identidad prevista del controlador se conecta, un proceso sin esa identidad es rechazado, el demonio sobrevive a un controlador que se desconecta sin aviso, y el túnel sigue llevando tráfico tras un reinicio controlado. Una conexión de gestión correcta demuestra solo el plano de control. No dice nada sobre si funciona el tráfico de aplicaciones privadas, así que pruébelo por separado. Anote los cuatro resultados donde el siguiente operador pueda encontrarlos.

La documentación de la interfaz de gestión describe el modelo de un solo cliente y la naturaleza privilegiada del protocolo, y esa es la parte que merece la pena leer antes de apuntarle un panel.