Surveiller un VPN sur routeur sans croire à un seul voyant d'état

La page d'état indique connecté, le voyant est vert, et le bureau n'atteint pas le serveur de fichiers. L'un de ces faits concerne le tunnel, l'autre le chemin qui le traverse. Surveiller les deux, c'est la différence entre une alerte exploitable et une alerte qu'on apprend à ignorer.

Cinq contrôles, dans l'ordre, du pair vers l'extérieur.

Contrôle 1 : état du pair ou de l'association

Chaque protocole expose son propre état. WireGuard montre la dernière poignée de main et les compteurs de transfert par pair via wg show. OpenVPN écrit l'état de session dans son fichier d'état ou son interface de gestion, et IPsec expose les associations de sécurité via des outils comme ipsec statusall. Le piège est de lire un horodatage comme un verdict : un pair WireGuard inactif sans rien à envoyer ne fera pas de poignée de main récente, et ce n'est pas une panne.

Comparez l'horodatage au trafic attendu et aux réglages de keepalive avant d'appeler quelqu'un.

Contrôle 2 : la route sélectionnée

Une interface de tunnel peut exister alors que rien n'y est routé. Vérifiez la table de transfert pour la destination qui vous intéresse, pas pour le sous-réseau propre du tunnel. Si le préfixe manque ou pointe ailleurs, l'état du pair est sans importance.

Ce contrôle attrape la panne qu'un voyant d'état ne montre jamais.

Un second contrôle utile compare aussi l'adresse source. ip route get 10.20.5.10 renvoie le prochain saut, l'interface et la source préférée, et une mauvaise source suffit à casser le trafic retour à l'extrémité distante. Notez le triplet attendu une fois, puis alertez quand un élément change. Cette seule ligne attrape les changements de NAT, les instabilités d'interface et les erreurs de routage par politique.

Contrôle 3 : un chemin applicatif autorisé

Testez quelque chose de représentatif de l'exigence réelle. Un ping émis par le routeur part de l'adresse et de la politique du routeur, qui peuvent différer du trafic LAN transféré, et beaucoup d'hôtes limitent ICMP. Si l'exigence est un service privé, testez ce service sur son vrai port.

Gardez le volume de sonde modeste. Une boucle de supervision ne doit pas devenir le trafic qu'elle mesure.

Contrôle 4 : ce qui a changé et quand

Corrélez les changements WAN, les renouvellements de clés, les retraits de routes et les échecs applicatifs sur une même chronologie. Distinguez une panne de tunnel d'une route de secours qui rétablit discrètement l'accès Internet ordinaire, car toutes deux produisent des rapports utilisateurs identiques et des diagnostics opposés. Les erreurs de fuseau horaire inverseront l'ordre, normalisez donc avant de comparer. La chronologie est ce qui transforme quatre contrôles en cause.

Conservez les journaux pour les transitions, pas pour la charge utile.

Contrôle 5 : l'alerte doit nommer la frontière

Une alerte qui dit VPN en panne envoie quelqu'un au mauvais endroit une fois sur deux. Une alerte qui dit poignée de main du pair périmée depuis douze minutes, route vers 10.20.0.0/16 absente ou sonde vers le port 445 en échec pointe un contrôle précis.

Tenez des compteurs opérationnels plutôt que de parcourir les charges utiles. Les compteurs répondent à la question de supervision sans collecter de contenu dont vous n'avez pas besoin.

Et laissez la politique de bascule décider de la suite. La supervision doit identifier quelle frontière a échoué, non autoriser un contournement large chaque fois qu'une sonde échoue. Le manuel OpenVPN 2.6 documente le fichier d'état et l'interface de gestion qui rendent le premier contrôle scriptable.