La politique IPsec engloutit votre trafic local : comment le savoir

L’imprimante posée sur le bureau cesse de répondre dès que le tunnel monte, et rien dans la configuration du tunnel ne mentionne l’imprimante. Ce qui s’est généralement passé, c’est qu’une plage protégée a été écrite si large qu’elle l’inclut, si bien que la machine cherche désormais à chiffrer un trafic qui devait rester sur le segment local. Lire la politique installée explique la capture ; la resserrer au bon endroit maintient le trafic distant protégé. Le trajet entre la requête qui échoue et la politique correspondante prend quelques minutes.

Suivez le flux avant de modifier un sélecteur

Partez de la requête qui échoue et notez quatre valeurs : l’adresse source utilisée par la machine, la destination exacte, la route que choisit le noyau et la politique qui correspond à ce couple.

Ces quatre faits décident si la capture est voulue ou accidentelle. Une destination qui tombe dans le sélecteur distant est protégée par conception, même si la conception était erronée. Une destination hors de ce sélecteur qui est quand même capturée signifie que quelque chose d’autre correspond, et modifier le sélecteur n’y changera rien. Les deux cas sont courants, et une seule commande les distingue.

Faites-le avant de modifier quoi que ce soit, car le cas intéressant est le sous-réseau local qui recoupe une plage privée protégée par la connexion. Des préfixes familiers comme 192.168.0.0/16 apparaissent dans de nombreux réseaux, et un sélecteur écrit pour l’un d’eux peut discrètement couvrir le vôtre.

Trois sortes de local qui se comportent différemment

Une destination attribuée à cet hôte, une destination sur le même lien et une destination derrière une autre interface sont trois cas différents. Le noyau traite chacun différemment lorsqu’il décide si le trafic doit être protégé.

Le trafic émis par la passerelle elle-même n’est pas non plus identique au trafic transmis depuis un client. Une politique qui semble correcte pour le trafic transmis peut capturer la session de gestion de la passerelle, et c’est ainsi qu’un administrateur perd l’accès pendant qu’il répare le tunnel.

L’habitude utile est de nommer le cas à voix haute : ce paquet vient-il de moi, va-t-il vers mon lien ou passe-t-il par moi ? Chaque réponse désigne un endroit différent à resserrer. Écrire le cas empêche aussi la personne suivante de refaire le même travail.

Quand la plage protégée est tout un espace privé, les trois cas peuvent y tomber à la fois, et le symptôme devient une machine qui n’atteint plus rien sauf le point de terminaison du tunnel.

Lisez la politique installée, pas le fichier

Les fichiers de configuration décrivent l’intention ; le noyau détient les politiques qui correspondent réellement. Affichez les deux et traitez un écart comme le premier constat.

Ces commandes montrent la route choisie pour la destination et les politiques installées dans chaque direction :

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

La route vous dit quelle interface le paquet utiliserait. La liste des politiques vous dit si un modèle est ensuite appliqué à ce paquet, et la liste des connexions montre quels sélecteurs le démon croit avoir installés. Si la destination apparaît dans un sélecteur distant, vous avez trouvé la capture sans deviner.

Resserrez le sélecteur ou contournez la destination

Il existe deux réparations prises en charge, et elles répondent à des questions différentes. Resserer le sélecteur dit que cette connexion ne protège qu’une plage plus petite, ce qui est correct quand la plage plus large était une erreur. Ajouter un contournement dit que cette destination précise ne doit jamais être protégée, ce qui est correct quand la plage protégée est réellement large et qu’une destination fait exception.

Choisissez la première quand vous pouvez, car un sélecteur plus petit est plus facile à comprendre et apparaît dans la définition de la connexion. Choisissez la seconde quand la plage large est intentionnelle et que l’exception est un hôte ou un sous-réseau que vous pouvez nommer.

Les deux appartiennent à la configuration qui possède la connexion. Une règle d’exécution ajoutée à la main disparaît à la prochaine reconnexion, et la panne revient à un moment où plus personne ne se souvient du contournement.

Des exceptions qui survivent à une réinstallation

Après la modification, répétez la même requête inoffensive et regardez les mêmes compteurs. La destination locale doit répondre, et la destination distante voulue doit toujours afficher du trafic chiffré.

Ces deux vérifications confirment que l’exception a survécu et que la protection n’a pas :

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Déconnectez ensuite le tunnel volontairement et reconnectez-le, puis répétez les deux. Une exception qui fonctionne avant la reconnexion et échoue après a été appliquée à la mauvaise couche, et c’est la façon la plus courante dont ce problème revient.