Comment vérifier qu'un tunnel VPN sous Linux est réellement actif

Cron redémarre toutes les dix minutes un VPN parfaitement sain, et la même tâche laisse un tunnel mort tourner pendant une semaine. Les deux échecs viennent de traiter «actif» comme un fait unique alors qu'il en compte au moins quatre. Un périphérique peut être activé administrativement, correctement routé, entièrement chiffré et pourtant ne rien transporter d'utile. Séparez d'abord les observations, et la vérification s'écrit presque toute seule.

Les indicateurs du lien décrivent l'appareil, pas le chemin

La vérification que tout le monde copie cherche une adresse matérielle composée de zéros. Cette astuce distingue une véritable interface d'un espace réservé chez certains pilotes et ne prouve rien chez les autres, car un périphérique tun n'a aucune adresse MAC à déclarer. ip -brief link show tun0 donne plutôt des indicateurs : UP signifie qu'un administrateur a activé l'appareil, et LOWER_UP signifie que le pilote considère le lien utilisable. Lus ensemble, ils indiquent que l'appareil existe et n'est pas désactivé administrativement. Ni l'un ni l'autre ne dit qu'un paquet a où aller.

OpenVPN crée son périphérique tun avant que les routes soient installées, si bien que les indicateurs peuvent sembler parfaits alors que rien n'est routé. Traitez-les comme une condition préalable, jamais comme la réponse.

Demandez où irait un paquet

La recherche de route répond à la question que les indicateurs ne peuvent pas résoudre. ip route get 10.8.0.1 from 10.8.0.2 nomme l'interface, l'adresse source et la table que le noyau utiliserait, ce qui est exactement ce contre quoi un tunnel scindé doit être vérifié. Sans l'adresse source, vous posez une autre question, et avec le routage par politiques la réponse peut différer selon la source. C'est le test honnête le moins coûteux, car il consulte les mêmes règles que votre trafic.

Pour WireGuard, ajoutez la poignée de main. wg show affiche un horodatage de la dernière poignée de main par pair, et un horodatage qui cesse d'avancer signifie que le pair a disparu, quoi que disent les indicateurs de l'interface. Une interface configurée sans poignée de main récente est l'un des faux positifs les plus courants dans une supervision maison.

La table 220 raconte l'histoire d'IPsec

strongSwan installe les routes des sélecteurs négociés dans la table 220 lorsque l'installation des routes est activée. ip route list table 220 sépare donc le négocié du routé : une table vide à côté d'une connexion chargée signifie que les SA IKE et CHILD sont montées alors qu'aucun trafic n'y est dirigé. Vérifiez ip xfrm state à côté, puisqu'elle liste les associations de sécurité installées et leurs points de terminaison.

Une politique piège est le cas auquel il faut faire attention. Elle attend un trafic intéressant au lieu de le router, si bien que la table reste vide jusqu'à ce que quelque chose déclenche le tunnel.

L'état du gestionnaire et l'état du démon sont des listes différentes

NetworkManager ne liste que les connexions qu'il possède. nmcli -t -f NAME,TYPE connection show --active ne renvoie rien pour un tunnel lancé directement par wg-quick ou par un démon OpenVPN.

Cette distinction compte quand un script doit décider auquel des deux gestionnaires demander. Choisissez celui qui possède réellement le tunnel sur cet hôte et ignorez le silence de l'autre. Si les deux existent, décidez lequel fait autorité et désactivez le second, car deux gestionnaires qui réécrivent des routes sur une seule interface produisent des pannes que personne ne peut reproduire. Une entrée absente est une information sur le gestionnaire, pas sur le tunnel.

Conditionnez l'étape suivante à la sonde dont elle a besoin

Sonder un port UDP ne prouve rien sur la disponibilité, car UDP n'a pas de poignée de main et nc -u réussit dès que le paquet part. Sondez ce que l'étape suivante consomme vraiment : une connexion TCP vers le port redirigé, une requête vers un hôte à l'intérieur du tunnel, un nom qui ne se résout que là-bas. Bornez l'attente par un délai d'expiration et un nombre de tentatives, et échouez bruyamment quand elle s'épuise.

Les crochets battent le sondage quand le client les propose. --up et --down les scripts d'OpenVPN s'exécutent après que l'interface a changé d'état, ce qui supprime entièrement la course, mais ils s'exécutent avec les privilèges que le démon a conservés. Si OpenVPN est descendu vers un compte non privilégié via user et group, le crochet s'exécute sous ce compte. Redémarrer un service système exige alors sudo pour autoriser exactement cette commande. Confiez la nouvelle tentative au gestionnaire de services plutôt qu'à une boucle cron : une politique de redémarrage bornée avec une limite de démarrages fait apparaître un tunnel cassé, tandis qu'une boucle sans borne le cache indéfiniment.