Enfermé dehors de votre serveur VPN : gardez une seconde voie d’accès
Un tunnel cassé ne devrait pas vous retirer aussi la possibilité de réparer le serveur. Planifiez, testez et révisez une voie administrative indépendante avant d’en avoir besoin.
Vous ouvrez la console, changez une règle de pare-feu, et le tunnel par lequel vous étiez connecté disparaît. Le changement était correct, le rechargement ne l’était pas, et la seule route de retour vers la machine est maintenant celle que vous venez de casser. Une seconde voie d’entrée est une décision de conception, et elle doit exister avant la panne, pas pendant.
Passez en revue ce qui vous reste
Partez de l’écran de console devant vous et listez les voies qui ne dépendent pas du tunnel. Une console web du fournisseur avec une session série ou VNC en est une. Une interface d’administration sur un réseau séparé en est une autre. L’accès physique est la troisième, et c’est celle dont les gens découvrent l’absence au pire moment.
| Path | Depends on | Usually fails when |
|---|---|---|
| Provider console | Account access and the provider's own API | Credentials live in a wiki only reachable over the tunnel |
| Management subnet | A second interface and its own routing | The bad change was a global route or firewall policy |
| Second tunnel | A different listener, port and credentials | Both listeners were changed in the same edit |
| Physical or local console | Being in the building | Nobody has been in the building for a year |
Lisez la troisième colonne comme une liste de défaillances et non comme une abstraction. Deux de ces voies échouent généralement pour la même raison. Le tableau est la façon de le remarquer avant qu’une panne ne vous l’explique.
L’indépendance est une question de dépendances
Un compte de secours n’est pas indépendant si son mot de passe est stocké dans un service auquel vous accédez par le tunnel. Un second VPN sur le même hôte, le même port et la même politique de pare-feu n’est pas indépendant non plus, car le changement qui a cassé le premier casse les deux.
Descendez la chaîne et nommez ce dont chaque étape a besoin. L’accessibilité réseau, la résolution de noms, une source d’authentification et le service d’administration lui-même sont quatre dépendances distinctes, et une voie qui en partage une hérite de cette défaillance.
La voie jamais testée mérite sa propre méfiance. Une console qui n’a pas été ouverte depuis des mois peut exiger une réinitialisation du mot de passe par courriel, et cette boîte aux lettres peut être hébergée sur la machine que vous ne pouvez pas atteindre. Testez la voie pendant que tout fonctionne et vous découvrirez cela un après-midi tranquille.
Utilisez la seconde voie pour un changement contrôlé
Depuis la console, prenez un instantané ou copiez la configuration que vous êtes sur le point de modifier. Changez une chose. Rechargez le service et lisez le résultat avant de toucher à autre chose, car deux changements à la fois transforment un dépannage en expérimentation.
Gardez la session de secours ouverte pendant que vous le faites. Toute la valeur de la seconde voie est qu’elle survit à ce que vous modifiez, donc la fermer d’abord supprime la seule propriété qui la rendait utile.
Vérifiez depuis la voie de secours, pas de mémoire
La vérification qui compte est de savoir si la voie normale revient, et la session de secours est là où vous le confirmez dans l’ordre :
systemctl status openvpn-server@server --no-pager ss -lntup | grep -E ':(1194|443)\b' nft list ruleset | sed -n '1,40p' journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30
Lisez d’abord l’état du service, puis l’écouteur, puis les règles, puis le journal. Un service qui tourne sans écouteur désigne la configuration du service, tandis qu’un écouteur sans règles accessibles désigne le filtrage. L’ordre compte parce que chaque étape resserre la suivante, et sauter au journal revient souvent à lire des erreurs qui décrivent le symptôme et non la cause.
La documentation de systemctl couvre le comportement d’état et de redémarrage utilisé ici, y compris la façon dont un rechargement échoué laisse le processus précédent en marche. Restaurer une révision cohérente vaut mieux que se reconnecter sans cesse depuis un client incapable de réparer le serveur. Si la condition de retour arrière définie avant le changement est remplie, restaurez et arrêtez.
Tenez l’inventaire à jour
Révisez la liste d’accès lorsque les personnes ou l’infrastructure changent. Testez la voie de secours pendant que tout fonctionne. Retirez les comptes que personne n’a utilisés depuis la dernière réorganisation. Deux comptes obsolètes et un certificat expiré sont un petit nettoyage un mardi et une panne un dimanche.
Notez qui peut utiliser chaque voie, ce qu’elle permet et comment les identifiants sont renouvelés. Une voie de secours sans responsable devient une entrée oubliée, ce qui est un autre type de défaillance que d’être enfermé dehors.