Vous démarrez un client VPN via SSH ? Épinglez d’abord votre propre route

Vous vous connectez en SSH à un hôte de compilation, y démarrez le client VPN, et la session cesse de répondre. Rien n’a planté, et rien ne semble mal configuré au sens évident. Le client a installé une route par défaut, si bien que les réponses vers votre poste de travail sortent désormais par le tunnel, où l’adresse de votre poste de travail n’est pas routable. Le plus intéressant est que ce résultat était prévisible, et le correctif est une route écrite avant que le client ne démarre. Supposons un serveur avec une seule carte réseau, une passerelle 192.0.2.254 et un administrateur qui se connecte depuis 203.0.113.9.

Enregistrez le chemin avant de commencer

ip route show default nomme la passerelle et l’interface actuelles, tandis que ip route get 203.0.113.9 montre quelle interface et quelle adresse source le noyau utiliserait pour votre session. Conservez les deux sorties. Une fois le tunnel monté, ces deux commandes devraient toujours décrire le chemin physique, et si elles décrivent le tunnel, la session vit déjà sur du temps emprunté.

C’est la connexion déjà établie qui compte, alors ne validez pas seulement avec une nouvelle connexion. Une nouvelle session peut réussir brièvement grâce à un état que l’ancienne ne possède plus.

Épinglez l’adresse dans la configuration du client lui-même

Une route ajoutée à la main disparaît au redémarrage et entre en course avec les mises à jour de table du client, alors placez l’exception là où la table est gérée. Sous OpenVPN le mot-clé net_gateway se résout vers la passerelle qui existait avant le tunnel, donc route 203.0.113.9 255.255.255.255 net_gateway maintient exactement une adresse en dehors. WireGuard nécessite une autre approche car wg-quick gère lui-même les routes : définissez Table = off et ajoutez l’exception dans PostUp, avec un PostDown correspondant qui la retire. Les deux formes expriment la même intention, et toutes deux limitent l’exception à une adresse plutôt que d’affaiblir le tunnel pour tout.

Pour IPv6 la même idée prend un préfixe d’hôte unique, et le cas du transport encapsulé mérite d’être retenu : si la connexion extérieure du tunnel lui-même vit à une adresse fixe, cette adresse doit rester en dehors du tunnel qu’elle transporte, sinon le client achemine son propre transport en lui-même.

Ou retirez la table principale de l’équation

Quand plusieurs services de l’hôte doivent conserver leur chemin normal, cessez de modifier la table principale et donnez au client la sienne. Un espace de noms réseau avec une paire veth fait cela proprement : la route par défaut du client vit dans une autre pile et seuls les processus lancés à l’intérieur l’utilisent. Le routage par politiques atteint un endroit similaire pour une destination, en envoyant le trafic correspondant vers une table dédiée dont la route par défaut pointe encore vers la passerelle physique. Chacune des approches laisse la table principale de l’hôte sans nouvelle route par défaut, et c’est cette propriété qui maintient SSH en train de répondre.

Les deux sont plus de mécanique qu’une seule route d’hôte, et les deux en valent la peine quand plus d’une chose sur la machine doit survivre au tunnel.

Partez du principe que l’épinglage peut échouer

Une route liée à votre adresse publique actuelle se casse à l’instant où votre fournisseur la réattribue. Un serveur distant a alors besoin d’un chemin qui ne dépend pas de cette adresse : une console, une seconde interface de gestion ou un hôte de rebond qui reste hors du tunnel.

Deux garde-fous coûtent dix minutes. Un chien de garde qui arrête le client si une connexion de confirmation n’apparaît pas en quelques minutes transforme un verrouillage en retard, et une seconde session SSH maintenue ouverte pendant le changement prouve que l’exception fonctionne pendant que le tunnel est monté. Les keepalives seuls n’aident pas ici, car le chemin a disparu plutôt que d’être inactif ; ils rendent seulement la mort plus facile à remarquer.

Vérifiez dans l’ordre qui compte

Connectez le tunnel, confirmez que la route vers votre adresse sort toujours par la passerelle physique, puis ouvrez une nouvelle session. Si la nouvelle session fonctionne et que l’ancienne meurt quand même, la cause est le suivi de connexions ou un pare-feu à état plutôt que le routage, ce qui est un autre correctif.

Écrivez l’adresse épinglée et la commande qui l’a prouvée dans le journal des changements. La personne suivante qui démarrera un client sur cet hôte aura besoin des deux, et l’adresse aura peut-être changé d’ici là.