Un pair VPN fait un ping vers d’autres interfaces parce qu’elles sont locales

Un client WireGuard se connecte et fait un ping vers une adresse sur une interface complètement différente, et la réponse arrive. Les captures ne montrent la requête que sur le tunnel. Rien n’est cassé, et le paramètre de transfert soigneusement désactivé n’y est pour rien. Il s’agit d’une comparaison entre deux chemins qui se ressemblent sur un schéma et sont complètement différents dans le noyau.

Un chemin transfère des paquets pour quelqu’un d’autre ; l’autre les remet à l’hôte lui-même.

Un paquet adressé à l’hôte reste dans l’hôte

Le client distant envoie un paquet IP à une adresse que l’hôte possède. Le routage pose une question sur ce paquet : cette destination est-elle locale ? Chaque adresse que l’hôte détient apparaît dans la table de routage locale, et cette table est consultée avant la principale, si bien que le paquet va vers la pile propre de l’hôte au lieu de sortir par une autre interface. La réponse est générée localement, et elle revient par le tunnel parce que c’est de là que venait la requête.

C’est tout le mécanisme. Aucun transfert n’a lieu, aucun changement d’état d’interface n’intervient, et l’adresse en question n’a pas besoin d’être joignable depuis ailleurs.

Pourquoi ip_forward ne s’applique pas

Le transfert gouverne les paquets qui doivent sortir par une interface différente de celle par laquelle ils sont arrivés. Un ping vers l’hôte lui-même ne prend jamais ce chemin : le paquet est consommé localement et la réponse est générée localement. Régler net.ipv4.ip_forward=0 ne change donc rien ici, et une règle de la chaîne de transfert ne voit jamais ce trafic. Le bon contrôle se situe sur le chemin d’entrée, limité par l’interface d’entrée ou la source.

C’est pourquoi désactiver le transfert et supposer que l’hôte est isolé produit un faux sentiment de sécurité.

Lisez la table locale qui a décidé

ip rule show signale normalement une règle de priorité zéro qui envoie d’abord toutes les recherches vers la table locale, et ip route show table local liste les adresses propres de l’hôte avec une portée locale. Cette table inclut des adresses sur des interfaces administrativement désactivées mais toujours configurées. Les adresses IPv4 attribuées statiquement survivent généralement à une chute du lien, et c’est ainsi qu’un ping vers un pont hors service peut encore réussir et surprendre l’opérateur.

IPv6 n’est pas d’accord précisément sur ce point. Ses adresses sont ordinairement retirées lorsque le lien tombe, sauf si keep_addr_on_down est défini. Comparez les familles au lieu de supposer qu’une règle couvre les deux.

Ce qu’un pair atteint réellement

Une réponse provenant de l’adresse propre du routeur sur un segment ne dit rien des machines derrière ce segment. Le pair ne peut pas atteindre un hôte derrière l’autre interface par ce chemin ; il n’atteint que les adresses que le routeur possède lui-même. Tester un service sur un hôte LAN séparé, plutôt que de pinger l’adresse du routeur, est ce qui établit si le transfert est autorisé du tout.

Restreindre un pair aux services liés à l’adresse du tunnel est une question de politique d’entrée. Autorisez le service voulu sur l’interface du tunnel et limitez les sources qui peuvent l’utiliser, car le paquet y arrive réellement.

Vérifiez aussi les adresses que vous comptiez retirer. Retirer une adresse d’une interface est plus fiable que d’empiler des règles de pare-feu sur une adresse obsolète.