Por qué nc -uz no puede demostrar que un servidor OpenVPN está listo

Ejecutar nc -uz contra un servidor OpenVPN no mide casi nada, y el manual de OpenBSD lo dice en sus advertencias: los escaneos UDP en ese modo informan de éxito tanto si algo escucha como si no. El estado de salida refleja el envío local, no el estado remoto, así que un supervisor que confía en él mantiene un servidor muerto marcado como sano mientras la tabla de procesos parezca verosímil. Sustituirlo empieza por decidir qué pregunta debe responder la comprobación, porque proceso, oyente, autenticación y alcance de la aplicación son cuatro observaciones distintas. Una sonda que nombra una de ellas es útil; una sonda que implica las cuatro es una carga.

Qué puede y qué no puede observar una sonda UDP

nc -uz envía un datagrama y sale, y el estado que devuelve describe el envío local. Un puerto cerrado puede responder con ICMP port unreachable, pero el comportamiento documentado de este modo de escaneo no lo convierte en un fallo, y un puerto filtrado no produce ninguna respuesta. Por tanto, silencio y éxito significan lo mismo para quien llama.

Eso convierte la sonda en una prueba de la pila local, no del servidor. No establece que el host sea alcanzable, que el puerto esté vinculado, que el proceso OpenVPN se esté ejecutando o que un cliente pudiera autenticarse. Una prueba de conexión TCP es más fuerte porque el apretón de manos da una respuesta definitiva, pero solo cuando el despliegue escucha realmente en TCP. Cambiar la sonda a TCP en el mismo número prueba un oyente que puede que no exista, y contra un servidor solo UDP hará fallar un servicio sano.

Ajustar la sonda al transporte configurado va antes de confiar en cualquiera de los dos resultados. Un despliegue UDP necesita una señal distinta, no un protocolo distinto.

Tres quien llama, tres preguntas distintas

La disponibilidad depende de quién pregunta. El gestor de servicios que reinicia un proceso caído necesita saber que la instancia arrancó y vinculó su oyente. El balanceador de carga necesita saber que un cliente que llegue ahora sería aceptado. El sistema de monitorización necesita saber que el camino desde una red real sigue llevando una sesión hasta un recurso permitido.

No son la misma comprobación, y una sola sonda no puede cubrir honestamente las tres. Elige primero quién llama y luego la evidencia.

Construye la sonda a partir de la instancia actual

OpenVPN escribe una línea de arranque cuando una instancia termina de inicializarse, y esa línea es una evidencia útil sobre el arranque local. Léela del arranque actual y no de la cola de un archivo al que se añade, porque un éxito de la semana pasada se lee exactamente igual que un éxito de hace un minuto. Un servidor también puede terminar de inicializarse antes de que ningún cliente se haya conectado nunca, así que la línea no dice nada sobre la autenticación.

Para una comprobación de arranque, combina el estado del proceso con la evidencia actual del registro y un oyente que coincida con el transporte configurado. La comprobación debe fallar cuando el proceso está en ejecución pero no ha terminado de inicializarse, lo que significa que la consulta al registro tiene que limitarse a este arranque y a esta unidad.

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

Tres salidas, tres afirmaciones: la unidad está activa, este arranque produjo la línea de inicialización y algo ocupa el puerto UDP. Ninguna de ellas dice que un cliente pueda conectarse. Mantenlas separadas en la página de estado para que un incidente no colapse en un solo punto verde.

Rómpela a propósito y observa la sonda

Una sonda solo es fiable cuando la has visto fallar. Detén el servidor, ejecuta la sonda y confirma el resultado que esperas. Después vuelve a arrancarlo y confirma que la sonda se recupera sin ningún otro cambio.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

Lee el bloque línea por línea. El comando netcat imprime exit=0 mientras no hay nada vinculado, y ese es todo el problema en una línea. El primer ss no imprime nada, el reinicio tiene éxito, y el segundo ss vuelve a mostrar el oyente. Si tu sonda pasa contra el servidor detenido, está midiendo la pila local y nada más.

El fallo opuesto también importa. Una sonda que falla contra un servidor sano provoca reinicios que nunca hicieron falta, y un bucle de reinicios es una caída por sí mismo. Prueba las dos direcciones antes de conectar la sonda a cualquier cosa que pueda actuar sobre ella.

Qué debería decir la línea de estado

Anota qué frontera cubre cada comprobación: proceso, oyente, autenticación o aplicación. Una comprobación rara vez cubre más de una, y una página de estado que las comprime en “up” esconde la diferencia que importa durante un incidente. Para el camino de red, usa un cliente real con una identidad dedicada, deja que complete el apretón de manos y una operación permitida inofensiva, y luego desconéctalo. Eso ejercita el canal de control, la política de autenticación y el oyente en un solo paso.

Mantén esa identidad separada de los usuarios reales y dale los permisos mínimos que la comprobación necesita. Una sonda de disponibilidad con acceso amplio es una nueva superficie de ataque añadida por comodidad. Rota sus credenciales como cualquier otra cuenta, porque una sonda que deja de autenticarse parece exactamente un servidor que dejó de aceptar clientes.

Nombra la frontera en el texto de la alerta, para que el primer interviniente sepa si mirar la unidad, el zócalo, el certificado o la ruta. Una sonda que no puede decir qué demostró se confiará por la razón equivocada, y así es como la comprobación con netcat sobrevivió en primer lugar.