Pourquoi un serveur derrière un client VPN répond par le tunnel

Les connexions entrantes vers un hôte qui exécute aussi un client VPN échouent d’une manière très précise : la poignée de main arrive, le démon répond, et le client ne reçoit rien en retour. Rien ne bloque le port. La réponse est sortie par le tunnel, parce que le tunnel possède la route par défaut et que le noyau route les réponses selon la destination, non selon le souvenir de l’origine de la requête. Le démon est intact et le port est ouvert.

La réponse est routée, pas mémorisée

Un client VPN qui installe une route par défaut ajoute une entrée qui surclasse la passerelle LAN, soit par métrique, soit en divisant l’espace en deux moitiés plus précises. Les paquets sortants choisissent désormais l’interface du tunnel. Le noyau ne demande jamais d’où le paquet auquel il répond est arrivé à l’origine. Cette seule omission explique tous les symptômes qui suivent.

Le sens aller est routé selon la destination, et le sens retour aussi. La réponse est adressée à un client public, que le tunnel transportera volontiers. L’extrémité distante reçoit un paquet dont elle ne possède pas la source, le jette, et le client d’origine attend jusqu’à l’expiration du délai.

Un filtrage strict du chemin inverse peut rejeter le paquet entrant avant même que le démon ne le lise. Vérifiez ce compteur d’abord, car un rejet par filtre et une erreur de routage se ressemblent vus de l’extérieur.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

La première commande montre quelle route par défaut l’emporte actuellement. La deuxième indique si le filtrage strict s’applique globalement ou par interface, et la troisième montre toute règle de chaîne de transfert qui pourrait être impliquée.

Trois façons de conserver le chemin de retour

Exclure la destination du service du tunnel est l’option la plus étroite. Une route d’hôte pointée vers la passerelle LAN, plus un démon lié à l’adresse physique plutôt qu’à toutes les adresses, garde ce seul flux hors du tunnel. Le changement est local et facile à annuler.

Le routage par politiques est la réponse générale. Une règle fondée sur l’adresse source ou sur une marque de pare-feu sélectionne une table dont la route par défaut pointe vers la passerelle WAN, tandis que les connexions propres de l’hôte continuent d’utiliser le tunnel. Gardez la priorité explicite pour que la règle ne soit pas masquée plus tard.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Les deux premières commandes construisent le chemin alternatif pour les réponses issues de l’adresse publique. La troisième demande au noyau quel chemin prendraient exactement cette source et cette destination, et c’est ainsi que vous confirmez que la règle a un effet.

La traduction de source est la troisième option et la seule qui survive à un routeur faisant déjà du NAT devant le service. La réponse doit revenir à ce routeur, et le masquage vers l’interface WAN y parvient tout en cachant le client des journaux du service. Remplacer la route par défaut à la main après la connexion est un diagnostic, car le client réécrit la table à la prochaine reconnexion.

Quand la machine route aussi pour un LAN

La même panne apparaît un saut plus loin quand l’hôte route pour les appareils derrière lui. Une connexion entrante est transférée vers un appareil interne dont le seul chemin de retour est le tunnel, et la réponse atteint le client externe depuis l’adresse du fournisseur. L’appareil interne fonctionne correctement tout le temps.

Le suivi des connexions voit alors une réponse pour un flux qu’il n’a jamais enregistré et la rejette. La traduction de destination livre la connexion entrante à l’appareil, et la traduction de source fait apparaître la réponse comme venant du routeur lui-même.

Une route de politique qui maintient le port transféré sur le WAN pendant que le trafic propre du routeur utilise le tunnel est l’équivalent le plus propre. Sans traduction de source, la réponse est adressée au client externe, et l’appareil interne n’a aucune route pour cette adresse.

Trois sondes qui séparent les causes

Lancez trois sondes : une connexion vers la machine depuis internet, une connexion depuis celle-ci vers un hôte public et une résolution de nom. Quand les deux premières divergent, le chemin de retour est en cause. Quand les noms échouent dans les deux sens, le résolveur est une autre panne qui ne fait que partager le tunnel.

Corrigez d’abord la question du routage, puis regardez les noms. Mélanger les deux, c’est ainsi qu’un serveur qui fonctionne est blâmé pour un résolveur cassé.

Notez quelle interface l’exception nomme et gardez la configuration sous contrôle de version. Une règle écrite contre une interface renommée après une mise à jour passe aujourd’hui et échoue après le prochain redémarrage.