Per què nc -uz no pot demostrar que un servidor OpenVPN està a punt

Executar nc -uz contra un servidor OpenVPN gairebé no mesura res, i el manual d’OpenBSD ho diu a les seves advertències: les exploracions UDP en aquest mode informen d’èxit tant si hi ha algú escoltant com si no. L’estat de sortida reflecteix l’enviament local, no l’estat remot, així que un supervisor que hi confia manté un servidor mort marcat com a saludable mentre la taula de processos sembli versemblant. Substituir-la comença per decidir quina pregunta ha de respondre la comprovació, perquè procés, oient, autenticació i abast de l’aplicació són quatre observacions diferents. Una sonda que n’anomena una és útil; una sonda que implica les quatre és un passiu.

Què pot i què no pot observar una sonda UDP

nc -uz envia un datagrama i surt, i l’estat que retorna descriu l’enviament local. Un port tancat pot respondre amb ICMP port unreachable, però el comportament documentat d’aquest mode d’exploració no ho converteix en un error, i un port filtrat no produeix cap resposta. Per tant, silenci i èxit signifiquen el mateix per a qui crida.

Això converteix la sonda en una prova de la pila local, no del servidor. No estableix que l’amfitrió sigui abastable, que el port estigui lligat, que el procés OpenVPN s’estigui executant o que un client pogués autenticar-se. Una prova de connexió TCP és més forta perquè l’encaixada de mans dona una resposta definitiva, però només quan el desplegament escolta realment en TCP. Canviar la sonda a TCP al mateix número prova un oient que potser no existeix, i contra un servidor només UDP farà fallar un servei saludable.

Fer coincidir la sonda amb el transport configurat va abans de confiar en qualsevol dels dos resultats. Un desplegament UDP necessita un senyal diferent, no un protocol diferent.

Tres qui criden, tres preguntes diferents

L’estat a punt depèn de qui pregunta. El gestor de serveis que reinicia un procés caigut ha de saber que la instància s’ha iniciat i ha lligat el seu oient. El balancejador de càrrega ha de saber que un client que arribi ara seria acceptat. El sistema de monitoratge ha de saber que el camí des d’una xarxa real encara porta una sessió fins a un recurs permès.

No són la mateixa comprovació, i una sola sonda no pot cobrir honestament les tres. Tria primer qui crida i després l’evidència.

Construeix la sonda a partir de la instància actual

OpenVPN escriu una línia d’inici quan una instància acaba d’inicialitzar-se, i aquesta línia és una evidència útil sobre l’inici local. Llegeix-la de l’inici actual i no de la cua d’un fitxer afegit, perquè un èxit de la setmana passada es llegeix exactament igual que un èxit de fa un minut. Un servidor també pot acabar d’inicialitzar-se abans que cap client s’hagi connectat mai, així que la línia no diu res sobre l’autenticació.

Per a una comprovació d’inici, combina l’estat del procés amb l’evidència actual del registre i un oient que coincideixi amb el transport configurat. La comprovació ha de fallar quan el procés s’està executant però no ha acabat d’inicialitzar-se, cosa que significa que la consulta al registre ha d’estar limitada a aquest arrencada i aquesta unitat.

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

Tres sortides, tres afirmacions: la unitat és activa, aquest arrencada ha produït la línia d’inicialització i alguna cosa ocupa el port UDP. Cap d’elles diu que un client es pugui connectar. Mantén-les separades a la pàgina d’estat perquè un incident no col·lapsi en un sol punt verd.

Trenca-la a propòsit i observa la sonda

Una sonda només és fiable quan l’has vist fallar. Atura el servidor, executa la sonda i confirma el resultat que esperes. Després torna’l a engegar i confirma que la sonda es recupera sense cap altre canvi.

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

Llegeix el bloc línia per línia. L’ordre netcat imprimeix exit=0 mentre no hi ha res lligat, i aquest és tot el problema en una línia. El primer ss no imprimeix res, el reinici té èxit, i el segon ss torna a mostrar l’oient. Si la teva sonda passa contra el servidor aturat, està mesurant la pila local i res més.

La fallada oposada també importa. Una sonda que falla contra un servidor saludable provoca reinicis que no calien, i un bucle de reinicis és una caiguda per si mateix. Prova les dues direccions abans de connectar la sonda a qualsevol cosa que hi pugui actuar.

Què hauria de dir la línia d’estat

Anota quina frontera cobreix cada comprovació: procés, oient, autenticació o aplicació. Una comprovació poques vegades en cobreix més d’una, i una pàgina d’estat que les comprimeix en “up” amaga la diferència que importa durant un incident. Per al camí de xarxa, fes servir un client real amb una identitat dedicada, deixa que completi l’encaixada de mans i una operació permesa inofensiva, i després desconnecta’l. Això exerceix el canal de control, la política d’autenticació i l’oient en un sol pas.

Mantén aquesta identitat separada dels usuaris reals i dona-li els permisos mínims que la comprovació necessita. Una sonda de disponibilitat amb accés ampli és una nova superfície d’atac afegida per comoditat. Rota les seves credencials com qualsevol altre compte, perquè una sonda que deixa d’autenticar-se sembla exactament un servidor que ha deixat d’acceptar clients.

Anomena la frontera al text de l’alerta, perquè el primer que respongui sàpiga si ha de mirar la unitat, el sòcol, el certificat o la ruta. Una sonda que no pot dir què ha demostrat es confiarà per la raó equivocada, i així és com la comprovació amb netcat ha sobreviscut en primer lloc.