Por que nc -uz non pode demostrar que un servidor OpenVPN está listo

Executar nc -uz contra un servidor OpenVPN non mide case nada, e o manual de OpenBSD dío nas súas advertencias: as exploracións UDP nese modo informan de éxito tanto se algo escoita como se non. O estado de saída reflicte o envío local, non o estado remoto, así que un supervisor que confía nel mantén un servidor morto marcado como san mentres a táboa de procesos pareza verosímil. Substituílo comeza por decidir que pregunta debe responder a comprobación, porque proceso, oínte, autenticación e alcance da aplicación son catro observacións distintas. Unha sonda que nomea unha delas é útil; unha sonda que implica as catro é unha carga.

Que pode e que non pode observar unha sonda UDP

nc -uz envía un datagrama e sae, e o estado que devolve describe o envío local. Un porto pechado pode responder con ICMP port unreachable, pero o comportamento documentado deste modo de exploración non o converte nun fallo, e un porto filtrado non produce ningunha resposta. Por tanto, silencio e éxito significan o mesmo para quen chama.

Iso converte a sonda nunha proba da pila local, non do servidor. Non establece que o host sexa alcanzable, que o porto estea ligado, que o proceso OpenVPN se estea executando ou que un cliente puidese autenticarse. Unha proba de conexión TCP é máis forte porque o aperto de mans dá unha resposta definitiva, pero só cando o despregamento escoita realmente en TCP. Cambiar a sonda a TCP no mesmo número proba un oínte que pode non existir, e contra un servidor só UDP fará fallar un servizo san.

Axustar a sonda ao transporte configurado vai antes de confiar en calquera dos dous resultados. Un despregamento UDP necesita un sinal distinto, non un protocolo distinto.

Tres quen chaman, tres preguntas distintas

A dispoñibilidade depende de quen pregunta. O xestor de servizos que reinicia un proceso caído necesita saber que a instancia arrancou e ligou o seu oínte. O balanceador de carga necesita saber que un cliente que chegue agora sería aceptado. O sistema de monitorización necesita saber que o camiño desde unha rede real segue levando unha sesión ata un recurso permitido.

Non son a mesma comprobación, e unha soa sonda non pode cubrir honestamente as tres. Escolle primeiro quen chama e despois a evidencia.

Constrúe a sonda a partir da instancia actual

OpenVPN escribe unha liña de arranque cando unha instancia remata de inicializarse, e esa liña é unha evidencia útil sobre o arranque local. Léaa do arranque actual e non da cola dun ficheiro ao que se engade, porque un éxito da semana pasada lese exactamente igual que un éxito de hai un minuto. Un servidor tamén pode rematar de inicializarse antes de que ningún cliente se conectase nunca, así que a liña non di nada sobre a autenticación.

Para unha comprobación de arranque, combina o estado do proceso coa evidencia actual do rexistro e un oínte que coincida co transporte configurado. A comprobación debe fallar cando o proceso está en execución pero non rematou de inicializarse, o que significa que a consulta ao rexistro ten que limitarse a este arranque e a esta unidade.

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

Tres saídas, tres afirmacións: a unidade está activa, este arranque produciu a liña de inicialización e algo ocupa o porto UDP. Ningunha delas di que un cliente poida conectarse. Manténas separadas na páxina de estado para que un incidente non colapse nun só punto verde.

Rómpaa a propósito e observa a sonda

Unha sonda só é fiable cando a viches fallar. Detén o servidor, executa a sonda e confirma o resultado que esperas. Despois volve arrincalo e confirma que a sonda se recupera sen ningún outro 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

Le o bloque liña por liña. O comando netcat imprime exit=0 mentres non hai nada ligado, e ese é todo o problema nunha liña. O primeiro ss non imprime nada, o reinicio ten éxito, e o segundo ss volve mostrar o oínte. Se a túa sonda pasa contra o servidor detido, está medindo a pila local e nada máis.

O fallo oposto tamén importa. Unha sonda que falla contra un servidor san provoca reinicios que nunca fixeron falta, e un bucle de reinicios é unha caída por si mesmo. Proba as dúas direccións antes de conectar a sonda a calquera cousa que poida actuar sobre ela.

Que debería dicir a liña de estado

Anota que fronteira cobre cada comprobación: proceso, oínte, autenticación ou aplicación. Unha comprobación raramente cobre máis dunha, e unha páxina de estado que as comprime en “up” agocha a diferenza que importa durante un incidente. Para o camiño de rede, usa un cliente real cunha identidade dedicada, deixa que complete o aperto de mans e unha operación permitida inofensiva, e despois desconéctao. Iso exercita a canle de control, a política de autenticación e o oínte nun só paso.

Mantén esa identidade separada dos usuarios reais e dálle os permisos mínimos que a comprobación necesita. Unha sonda de dispoñibilidade con acceso amplo é unha nova superficie de ataque engadida por comodidade. Rota as súas credenciais como calquera outra conta, porque unha sonda que deixa de autenticarse parece exactamente un servidor que deixou de aceptar clientes.

Nomea a fronteira no texto da alerta, para que o primeiro interviniente saiba se mirar a unidade, o zócolo, o certificado ou a ruta. Unha sonda que non pode dicir que demostrou confiarase pola razón equivocada, e así foi como a comprobación con netcat sobreviviu en primeiro lugar.