Pourquoi nc -uz ne peut pas prouver qu’un serveur OpenVPN est prêt

Lancer nc -uz contre un serveur OpenVPN ne mesure presque rien, et le manuel d’OpenBSD le dit dans ses réserves : les analyses UDP dans ce mode signalent un succès, que quelque chose écoute ou non. Le code de sortie reflète l’envoi local, pas l’état distant, donc un superviseur qui s’y fie garde un serveur mort marqué comme sain tant que la table des processus paraît plausible. Le remplacer commence par décider à quelle question la vérification doit répondre, car processus, écouteur, authentification et joignabilité de l’application sont quatre observations différentes. Une sonde qui en nomme une est utile ; une sonde qui implique les quatre est une charge.

Ce qu’une sonde UDP peut et ne peut pas observer

nc -uz envoie un datagramme et se termine, et le statut qu’il renvoie décrit l’envoi local. Un port fermé peut répondre par ICMP port unreachable, mais le comportement documenté de ce mode d’analyse n’en fait pas un échec, et un port filtré ne produit aucune réponse. Silence et succès signifient donc la même chose pour l’appelant.

Cela fait de la sonde un test de la pile locale, pas du serveur. Elle n’établit pas que l’hôte est joignable, que le port est lié, que le processus OpenVPN tourne ou qu’un client pourrait s’authentifier. Un test de connexion TCP est plus fort parce que la poignée de main donne une réponse nette, mais seulement quand le déploiement écoute réellement en TCP. Passer la sonde en TCP sur le même numéro teste un écouteur qui n’existe peut-être pas, et contre un serveur uniquement UDP, cela fera échouer un service sain.

Aligner la sonde sur le transport configuré vient avant de faire confiance à l’un ou l’autre résultat. Un déploiement UDP a besoin d’un autre signal, pas d’un autre protocole.

Trois appelants, trois questions différentes

La disponibilité dépend de qui pose la question. Un gestionnaire de services qui redémarre un processus planté doit savoir que l’instance a démarré et lié son écouteur. Un répartiteur de charge doit savoir qu’un client qui arrive maintenant serait accepté. Un système de supervision doit savoir que le chemin depuis un vrai réseau porte encore une session vers une ressource autorisée.

Ce n’est pas la même vérification, et une seule sonde ne peut pas honnêtement couvrir les trois. Choisissez d’abord l’appelant, puis la preuve.

Construisez la sonde à partir de l’instance actuelle

OpenVPN écrit une ligne de démarrage quand une instance termine son initialisation, et cette ligne est une preuve utile du démarrage local. Lisez-la depuis le démarrage actuel plutôt que depuis la fin d’un fichier complété, car un succès de la semaine dernière se lit exactement comme un succès d’il y a une minute. Un serveur peut aussi terminer son initialisation avant qu’un client ne se soit jamais connecté, donc la ligne ne dit rien de l’authentification.

Pour une vérification de démarrage, associez l’état du processus à une preuve de journal actuelle et à un écouteur qui correspond au transport configuré. La vérification doit échouer quand le processus tourne mais n’a pas terminé son initialisation, ce qui signifie que la requête de journal doit être limitée à ce démarrage et à cette unité.

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

Trois sorties, trois affirmations : l’unité est active, ce démarrage a produit la ligne d’initialisation et quelque chose occupe le port UDP. Aucune ne dit qu’un client peut se connecter. Gardez-les séparées sur la page d’état pour qu’un incident ne s’effondre pas en un seul point vert.

Cassez-la exprès et observez la sonde

Une sonde n’est fiable qu’une fois que vous l’avez vue échouer. Arrêtez le serveur, lancez la sonde et confirmez le résultat attendu. Puis redémarrez-le et confirmez que la sonde se rétablit sans aucun autre changement.

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

Lisez le bloc ligne par ligne. La commande netcat affiche exit=0 alors que rien n’est lié, et c’est tout le problème en une ligne. La première ss n’affiche rien, le redémarrage réussit, et la seconde ss montre de nouveau l’écouteur. Si votre sonde passe contre le serveur arrêté, elle mesure la pile locale et rien d’autre.

L’échec inverse compte aussi. Une sonde qui échoue contre un serveur sain provoque des redémarrages qui n’ont jamais été nécessaires, et une boucle de redémarrage est à elle seule une panne. Testez les deux directions avant de brancher la sonde à quoi que ce soit qui puisse agir dessus.

Ce que la ligne d’état devrait dire

Notez quelle frontière chaque vérification couvre : processus, écouteur, authentification ou application. Une vérification en couvre rarement plus d’une, et une page d’état qui les comprime en « up » cache la différence qui compte pendant un incident. Pour le chemin réseau, utilisez un vrai client doté d’une identité dédiée, laissez-le terminer la poignée de main et une opération autorisée inoffensive, puis déconnectez-le. Cela exerce le canal de contrôle, la politique d’authentification et l’écouteur en une seule étape.

Gardez cette identité séparée des vrais utilisateurs et donnez-lui les permissions minimales dont la vérification a besoin. Une sonde de disponibilité à accès large est une nouvelle surface d’attaque ajoutée par commodité. Faites tourner ses identifiants comme pour tout autre compte, car une sonde qui cesse de s’authentifier ressemble exactement à un serveur qui a cessé d’accepter des clients.

Nommez la frontière dans le texte de l’alerte, pour que le premier intervenant sache s’il doit regarder l’unité, la socket, le certificat ou la route. Une sonde qui ne peut pas dire ce qu’elle a prouvé sera crue pour la mauvaise raison, et c’est ainsi que la vérification netcat a survécu au départ.