Pourquoi une règle de port source casse l'un de vos chemins SSH

Deux entrées de gestion sur un même hôte, un seul port de service et une règle de stratégie censée aider les deux. La règle correspond au port source 22, envoie la recherche vers une table qui ne connaît que la valeur par défaut du WAN, et l'entrée VPN cesse de répondre aux nouvelles connexions tandis que l'entrée directe continue de fonctionner. Rien de tout cela n'est mystérieux une fois le sélecteur lu correctement. Un port source identifie un service, pas le chemin par lequel une connexion est arrivée.

Deux entrées, un seul port de service

L'hôte possède une adresse côté LAN et une adresse VPN, et sshd écoute sur les deux. Une session directe et une session tunnelisée partagent donc le port de service et ne diffèrent que par l'adresse locale qui reçoit la connexion.

Cette différence suffit à choisir un chemin de réponse, et c'est exactement la différence qu'une règle fondée sur le port écarte. Les deux sessions produisent des réponses dont le port source est 22, donc une règle qui correspond à ce port ne peut pas les séparer. Elle envoie les deux recherches vers la même table, et l'une d'elles reçoit une réponse qui ne convient pas. Le correctif consiste à faire correspondre l'attribut qui diffère réellement.

Donner à chaque entrée son propre port fonctionnerait aussi, et traiter cela comme une exigence est un choix de conception, non une propriété de SSH.

Lisez la règle, puis la table

Une règle de stratégie est un sélecteur ordonné, et la première qui renvoie une réponse utilisable met fin à la recherche. Lisez la liste dans l'ordre et notez quelle règle peut l'emporter.

Lisez ensuite la table vers laquelle cette règle pointe, car une règle qui se résout avec succès n'est pas une règle qui se résout utilement. Une table ne contenant qu'une route par défaut envoie la réponse issue du VPN par l'interface WAN. Une route plus spécifique dans une table ultérieure n'est jamais consultée, et c'est pourquoi ajouter une seconde table ne change si souvent rien. La table sélectionnée est ce qu'il faut inspecter.

ip -4 rule show
ip route show table 100
ip route show table main

Ces deux sorties ensemble expliquent le résultat ; l'une seule invite à une conclusion erronée.

Limitez la règle au flux que vous visez

L'attribut qui sépare les deux entrées est l'adresse source locale. Une règle correspondant à cette adresse envoie uniquement les sessions tunnelisées vers la table privée et laisse les sessions directes sur la table principale.

Cette règle doit être associée à une table contenant la route privée et le chemin de retour pour ce sous-réseau. Limitez les deux au trafic de gestion plutôt qu'à chaque service de l'hôte. Une règle qui capture tout le trafic de cette adresse redirigera aussi tout ce que l'hôte envoie depuis celle-ci. L'étroit l'emporte ici sur l'astucieux, car la personne suivante doit le lire.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Si les deux entrées sont traduites sur une seule adresse locale, cette distinction disparaît et la conception a besoin d'un état conscient de la connexion à la place.

Gardez le récepteur, l'autorisation et la sélection de réponse séparés

Trois choses distinctes doivent être vraies avant qu'une session fonctionne : l'adresse existe, le service écoute dessus et la réponse retrouve son chemin. Un changement de route ne corrige que la troisième.

La configuration du récepteur est son propre fichier et son propre rechargement, et plusieurs adresses d'écoute sont normales. L'authentification est encore une troisième décision, et une exception de routage ne donne accès à personne. Conservez la vérification de clé d'hôte, l'authentification de compte et les restrictions de source sur les deux entrées, et résistez à l'envie d'affaiblir les autres contrôles du tunnel pour qu'un seul chemin de gestion fonctionne.

Gardez un canal de récupération qui ne dépend pas du chemin que vous modifiez, car une erreur ici verrouille le correctif lui-même.

Prouvez-le avec une nouvelle session, pas une ancienne

Un terminal établi ne prouve rien, puisqu'il a été admis avant le changement. Ouvrez une session neuve via chaque entrée prévue.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Répétez ensuite la reconnexion VPN et réessayez, car une route qui survit à une reconnexion n'est pas la même qu'une route ajoutée à une table que la reconnexion vide. Observez les sources refusées séparément des sources autorisées, afin qu'une tentative bloquée ne se cache pas derrière une session qui fonctionne. Enregistrez l'adresse locale, la règle et la table à côté du résultat. Si vous divisez plutôt les ports, consignez-le comme une décision d'exploitation et non comme une limite de SSH.