Tester la récupération du serveur VPN après un redémarrage : que vérifier en premier

Redémarrez le serveur sans que personne ne soit connecté, puis connectez-vous depuis un réseau que vous ne contrôlez pas. Ce seul test répond à la question de savoir si la récupération est réelle, car un tunnel qui ne fonctionne qu'après l'exécution manuelle d'une commande n'est pas une récupération, c'est une réparation. La plupart des vérifications s'arrêtent trop tôt : le démon apparaît actif, l'interface apparaît, et la page ne se charge toujours pas. L'écart réside presque toujours dans la persistance des pièces autour du tunnel, pas dans la commande du tunnel elle-même.

Quatre propriétaires, quatre tests différents

Avant le redémarrage, nommez ce qui est censé ramener le tunnel. Le test que vous exécutez et la correction que vous appliquez dépendent tous deux de cette réponse, et il existe quatre propriétaires courants : une unité systemd pour le démon VPN, une unité d'instance wg-quick pour une interface WireGuard, un runtime de conteneurs ou un profil de gestionnaire de réseau. Si vous ne pouvez pas nommer le propriétaire, arrêtez-vous et trouvez-le, car un test de redémarrage sans chemin de démarrage attendu vous dit seulement que quelque chose s'est produit.

Chaque propriétaire conserve sa configuration ailleurs. Un serveur OpenVPN géré par systemd lit sa configuration au démarrage, donc ce qui se trouve dans le fichier au moment du démarrage est ce qui s'exécute. Une interface wg-quick tire ses adresses, ses routes et son DNS du même fichier, ce qui signifie qu'une interface montée à la main depuis un shell et jamais activée comme unité ne reviendra pas. Un conteneur ramène son point d'entrée, mais pas les modifications du pare-feu de l'hôte, sauf si celles-ci vivent en dehors du conteneur.

D'abord la base de référence, sinon le résultat ne veut rien dire

Capturez l'état de fonctionnement pendant qu'il fonctionne : adresses sur le tunnel, routes pour le sous-réseau client, règles NAT ou de transfert, le socket d'écoute et le sysctl de transfert. ip addr show wg0, ip route, nft list ruleset ou iptables-save, ss -lunp et sysctl net.ipv4.ip_forward suffisent sur la plupart des hôtes.

Notez comment le service est configuré pour démarrer, pas seulement qu'il fonctionne. systemctl is-enabled wg-quick@wg0 et systemctl is-active wg-quick@wg0 répondent à des questions différentes, et l'état activé est celui qui compte au démarrage, comme décrit dans systemctl(1). Pour OpenVPN, vérifiez quel modèle l'hôte utilise, car openvpn@server et openvpn-server@server sont des unités différentes avec des valeurs par défaut différentes.

Exécutez le redémarrage et lisez la première défaillance

Redémarrez volontairement, pendant une fenêtre que vous avez choisie, avec une console ou un chemin hors bande ouvert. Observez l'ordre des événements plutôt que l'état final : hôte joignable, unité activée, interface présente, routes installées, règles de pare-feu présentes, écouteur lié, client accepté. La première étape qui ne se produit pas est la constatation ; tout ce qui suit est du bruit.

Un démon peut être actif alors que le tunnel est inutilisable, et c'est le faux succès le plus courant. Le démarrage peut se terminer avant que le réseau soit en ligne si l'unité n'attend que network.target au lieu de network-online.target. Les fichiers référencés, tels que les certificats, les clés ou une CRL, peuvent être illisibles à ce moment-là parce qu'un montage ou un chemin de secrets n'est pas encore prêt. Aucun des deux problèmes n'apparaît dans systemctl status avant que vous ne lisiez le journal de l'unité.

Testez depuis l'extérieur de l'hôte. Un client sur le même LAN peut réussir par une route qu'aucun client distant n'utiliserait jamais, et une session SSH vers la machine ne prouve rien sur le tunnel. Connectez-vous, résolvez un nom interne, atteignez la ressource privée, puis reconnectez-vous une fois pour confirmer que l'état de révocation et les clés s'appliquent toujours.

Les trois conditions qui décident de votre correction

Si le tunnel revient mais que les clients n'atteignent rien, la défaillance est dans le routage ou la persistance du NAT. Si les clients ne peuvent même pas terminer une poignée de main, la défaillance est dans l'interface ou le matériel d'authentification. Si le service ne démarre jamais, la défaillance est dans le fichier d'unité ou ses dépendances. Ces trois branches mènent à des corrections différentes, et c'est pourquoi un redémarrage aveugle sans base de référence coûte plus de temps qu'il n'en fait gagner.

Faites la correction là où le réglage est possédé. Mettez le transfert dans un drop-in sysctl, mettez les règles NAT dans le jeu de règles qui se charge au démarrage, activez l'unité au lieu de la démarrer, et gardez les secrets sur un chemin qui existe avant le démarrage de l'unité. Ajouter une attente à l'unité masque une dépendance au lieu de la déclarer.

Inscrivez le résultat dans le runbook

Écrivez ce qui est revenu tout seul, ce que vous avez dû démarrer et combien de temps l'écart a duré. Incluez les commandes exactes que vous avez utilisées pour vérifier, afin que la personne suivante répète le test au lieu d'en inventer un. Si une étape a nécessité une commande manuelle, cette commande appartient à la configuration, pas au runbook comme étape permanente.

Planifiez ensuite le prochain test pour après le prochain changement de la pile réseau de l'hôte, pas pour une date calendaire dans six mois. Le mode de défaillance contre lequel vous vous protégez est une commande temporaire qui semblait permanente, et celles-ci apparaissent exactement lorsque quelqu'un modifie des règles de pare-feu ou déplace un service vers une nouvelle unité.