Pourquoi votre service Linux public répond finalement via le VPN

Rien dans la socket ne se souvient de l’interface qui a transporté la requête, donc une route par défaut VPN en tunnel complet peut capturer une réponse qui appartient au WAN. Le service n’ignore pas l’interface d’entrée ; Linux achemine une réponse générée localement selon la destination et la politique de source. Une règle basée sur la source peut envoyer uniquement les réponses du service via une table WAN complète, en laissant la sortie ordinaire sur le tunnel. Le port reste ouvert pendant que la réponse part par le mauvais chemin, ce qui explique pourquoi le symptôme semble unilatéral.

L’idée fausse : les réponses suivent l’interface par laquelle elles sont arrivées

Il semble logique qu’un paquet arrivant sur eth0 reparte sur eth0. Des filtres de paquets sans état peuvent être écrits ainsi, et tcpdump côté entrée montre la requête exactement là où on l’attend. Le routage ne fonctionne pas ainsi pour le trafic que l’hôte émet lui-même.

Une fois que le service accepte la connexion, sa réponse est un nouveau paquet généré localement. Le noyau consulte les règles de routage pour la destination et la source de la réponse, et la route par défaut du VPN est une réponse parfaitement valable. Rien dans la socket ne se souvient de l’interface qui a transporté la requête.

C’est pourquoi le symptôme semble unilatéral : les requêtes arrivent, les réponses disparaissent. C’est aussi pourquoi ajouter une règle de pare-feu pour le port d’entrée ne change rien. Le paquet n’est pas bloqué à l’entrée ; il est routé ailleurs à la sortie. Suivez la réponse avec une recherche qualifiée par la source et le détour devient visible.

Ce que le noyau route réellement : l’adresse source

L’élément à utiliser est l’adresse locale que le service emploie pour ses réponses. Sur un hôte dont l’adresse eth0 illustrative est 192.0.2.10/24 avec la passerelle 192.0.2.1, cette adresse est présente sur l’interface. Sur une VM cloud, l’adresse publique peut être traduite en amont et absente de l’invité ; utilisez donc l’adresse que l’hôte possède réellement.

Inspectez l’état actuel avant de réserver un numéro de table ou une priorité de règle. Des règles de politique existantes peuvent masquer une nouvelle règle, et une ancienne table portant le même numéro peut déjà contenir des routes sans rapport :

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Sélectionnez ensuite une table par source. La règle correspond aux réponses qui portent déjà 192.0.2.10, exactement le trafic terminé localement que vous voulez exempter. Le trafic transféré et les paquets provenant d’autres adresses locales ne correspondent pas.

Construisez une table de retour complète, pas une demi-route par défaut

Une table contenant seulement une route par défaut ne suffit pas. Le noyau doit encore résoudre la passerelle, et cette résolution exige le préfixe connecté dans la même table. Une table à laquelle ce préfixe manque échoue à la résolution de la passerelle même lorsque sa route par défaut semble correcte. Ajoutez les deux, puis pointez la règle de source vers la table :

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Utilisez le vrai préfixe et la vraie passerelle plutôt que de copier l’exemple. Une interface cloud configurée en /32 avec une passerelle sur le lien nécessite une route connectée différente, et une table construite à partir du mauvais préfixe échoue au premier saut. L’attribut src indique la source préférée pour cette route ; il ne remplace pas la règle de source.

L’ordre compte aussi. Une règle large avec un numéro de priorité plus bas est évaluée en premier, donc la règle de source doit être atteinte avant toute règle qui renverrait ce trafic vers la table principale. Vérifiez les priorités avec ip rule show après l’avoir ajoutée, pas seulement au démarrage.

Vérifiez avec une recherche qualifiée par la source

Demandez au noyau de router une destination de test depuis l’adresse du service. La réponse doit nommer eth0 et la passerelle WAN, pas le tunnel :

ip -4 route get 198.51.100.25 from 192.0.2.10

Établissez ensuite une nouvelle connexion autorisée et observez les deux directions. Une recherche qui sélectionne la bonne table alors que la connexion réelle échoue encore désigne le filtrage du chemin inverse ou une règle de pare-feu, pas la table. Vérifiez ces contrôles avant de désactiver quoi que ce soit globalement.

Placez les routes finales et la règle sous le gestionnaire de réseau qui possède l’interface. Les changements d’adresse, le renouvellement DHCP et les reconnexions VPN réécrivent tous l’état du noyau, et une règle ajoutée à la main disparaît ou pointe vers une passerelle périmée après l’événement suivant.

Où cette exception s’arrête

La règle exempte le trafic terminé localement depuis une adresse source. Elle ne couvre pas les ports publiés par Docker, le DNAT ni les services transférés via l’hôte, car ces paquets sont routés comme du trafic transféré et ne portent jamais la source locale de l’hôte de la même manière. Ces conceptions nécessitent généralement une marque posée à l’entrée et une règle qui correspond à cette marque.

Elle ne fait pas non plus apparaître l’adresse publique de l’hôte sur l’interface. Quand un NAT en amont possède cette adresse, la réponse doit encore sortir par le chemin que ce NAT attend, c’est pourquoi la table WAN doit refléter la passerelle et le préfixe d’origine plutôt qu’une plage publique devinée.

Documentez l’exception avec son numéro de table, sa priorité de règle et l’adresse source exacte. Le prochain changement du VPN ou de l’interface peut la casser silencieusement, et une note nommant les trois valeurs est plus rapide à vérifier que redécouvrir le symptôme à partir d’un rapport client.

Si le service répond encore par le mauvais chemin alors que la recherche qualifiée par la source réussit, comparez l’adresse source de la socket réelle avec celle de la règle. Un service lié à une adresse générique peut choisir une source différente de celle que vous avez testée, et cet écart constitue la lacune restante.