Gardez le SSH local quand l’hôte utilise un VPN sortant

Un petit serveur Linux utilise un VPN sortant pour l’application qu’il héberge, et l’administrateur veut toujours y accéder en SSH depuis le bureau voisin. C’est une exigence raisonnable, et elle ne demande généralement ni redirection de port, ni adresse du fournisseur, ni trou dans le tunnel. Ce qu’il lui faut, c’est un chemin d’administration conçu exprès au lieu d’hériter de ce que le client VPN a fait de la table de routage.

Les étapes ci-dessous supposent que l’administrateur se trouve sur le même LAN.L’administration à distance est un autre problème avec une autre réponse.

Liez SSH à l’adresse qu’utilisent les administrateurs

Commencez par l’écouteur.ss -ltnp | grep :22 montre à quoi sshd est lié, et un écouteur sur 0.0.0.0 accepte les connexions de toutes les interfaces, y compris le tunnel. Se lier à l’adresse du LAN est plus étroit et rend l’intention visible :ListenAddress 192.168.10.20 dans sshd_config, suivi d’un test de configuration et d’un rechargement. Une faute de frappe dans cette adresse est plus visible qu’un joker, parce que sshd refuse de démarrer quand l’adresse n’existe pas.

Gardez la vérification de clé d’hôte et l’authentification par utilisateur exactement telles qu’elles sont. « Ce n’est que le réseau local » n’est pas une méthode d’authentification, et un canal d’administration qui saute la vérification de clé parce que la route est courte est un canal d’administration qui attend d’être abusé. Une réservation DHCP ou une adresse statique rend la cible prévisible sans en faire l’identité publique du serveur.

Gardez la route du LAN hors du tunnel

Un hôte avec une adresse en 192.168.10.0/24 a une route connectée pour ce préfixe, et une route plus spécifique l’emporte sur la route par défaut du VPN dans la même table. C’est pourquoi le SSH local continue souvent de fonctionner tout seul quand le tunnel monte. Vérifiez-le au lieu de le supposer :ip route get 192.168.10.50 nomme l’interface et l’adresse source que le noyau utiliserait, et la réponse devrait être l’appareil du LAN, pas le tunnel. Répétez la vérification depuis la machine de l’administrateur aussi, car sa propre table décide si les paquets arrivent un jour. Deux hôtes sur le même câble peuvent ne pas être d’accord sur la direction qui est joignable.

L’hypothèse se brise en deux endroits. Une règle de routage par politique peut envoyer le trafic vers une table dont la route par défaut pointe dans le tunnel avant que la table principale ne soit consultée. Un client VPN doté d’une fonction de verrouillage ou de kill-switch peut aussi bloquer le trafic qui n’entre pas dans le tunnel, quel que soit ce que dit la table de routage.

Les VLAN de gestion routés sont l’autre cas. Si l’administrateur est en 192.168.50.0/24 derrière le routeur local, le serveur a besoin d’une route explicite pour ce préfixe via 192.168.10.1, et cette route doit survivre à une reconnexion. Gardez l’exception propre au préfixe de gestion ; une exception large pour les plages privées annule le but du tunnel.

Rendez l’exception du pare-feu aussi étroite que la règle

Si l’hôte fait tourner un pare-feu, autorisez SSH uniquement depuis la source de gestion et uniquement sur l’interface du LAN. Une règle qui autorise le port 22 de partout est plus large que le besoin et plus difficile à justifier en revue. Sur un hôte nftables la règle appartient à la chaîne d’entrée avec l’interface et la source appariées ; sur un hôte iptables l’équivalent est une paire de correspondances sur -i et -s. Commentez la règle avec le groupe d’administrateurs qu’elle sert, pour que le prochain audit n’ait pas à deviner pourquoi le port 22 est ouvert.

Vérifiez aussi le filtre propre au client VPN. Certains clients installent des règles qui écartent le trafic local par conception, et une règle de pare-feu correcte par-dessus un rejet au niveau du client ne change rien. Lisez la configuration du client avant de modifier le pare-feu de l’hôte, parce que deux filtres en série produisent une panne qui ne ressemble à aucun des deux.

Testez les deux états

Exécutez le test deux fois : une fois avec le tunnel connecté et une fois déconnecté. Dans chaque état, confirmez l’écouteur, la route et une connexion SSH réelle depuis la machine de l’administrateur. Un chemin qui ne fonctionne que pendant que le tunnel est monté n’est pas un chemin d’administration local ; c’est une coïncidence.

Redémarrez ensuite le tunnel pendant qu’une session SSH est ouverte. Une session qui survit prouve que le routage est stable ; une session qui tombe vous dit que le client réécrit les routes ou les filtres à la reconnexion, ce qu’il vaut mieux savoir avant un incident que pendant.

Notez l’adresse source depuis laquelle vous avez testé, car une règle écrite pour 192.168.10.50 échoue silencieusement quand l’ordinateur portable de l’administrateur passe sur un autre sous-réseau.

Écrivez le chemin de récupération dans le runbook

Décidez maintenant de ce qui se passe si le VPN sortant casse le chemin local. L’accès console, une seconde adresse de gestion ou une procédure documentée pour arrêter le client sont toutes des réponses légitimes, et n’importe laquelle vaut mieux que découvrir le problème au moment où vous devez vous connecter. Si le serveur est distant, le chemin local n’existe pas, et la conception correcte est une route d’accès distant approuvée et séparée ou un bastion plutôt qu’un port public exposé.

Gardez les deux rôles séparés dans la documentation : le SSH local pour l’administrateur qui est à proximité, et le tunnel sortant pour le trafic de l’application. Quand ces rôles sont écrits, un changement futur de l’un ou de l’autre a un endroit évident où être vérifié, et la personne suivante n’a pas à redécouvrir pourquoi un serveur avec un VPN répond encore sur son adresse LAN.