Les réponses du VPN Linux disparaissent ? Vérifiez rp_filter et la route

Les requêtes quittent la machine, le pair VPN répond, et la réponse n'atteint jamais la socket. Le tunnel est monté, les journaux du pair montrent l'envoi du paquet, et rien dans l'application n'explique ce silence. Sous Linux, l'un des suspects habituels est le filtrage du chemin inverse : un paquet IPv4 entrant peut être rejeté lorsque la validation de source ne s'accorde pas avec la route que le noyau attend pour cette source. Le parcours dans l'ordre vous dit si c'est la cause ou une coïncidence. Il vous évite aussi de désactiver un contrôle de sécurité pour réparer une route manquante.

Ce que décide la validation de source

Le noyau vérifie si l'adresse source d'un paquet est plausible pour l'interface par laquelle il est arrivé, en consultant la table de routage pour une route de retour vers cette source. Si la route inverse pointe ailleurs, le paquet peut être abandonné avant qu'une règle de pare-feu ou une socket d'application ne le voie. Cette vérification existe pour rendre certains schémas d'usurpation plus difficiles, et c'est aussi pourquoi les conceptions asymétriques et routées par politique s'y heurtent alors que tout client ordinaire du même réseau fonctionne bien. Les clients ordinaires ont un routage symétrique, ce que la vérification suppose exactement.

Le mot important est plausible. Le paquet peut être parfaitement légitime et échouer quand même à la vérification, car ce n'est pas la légitimité qui est testée.

Lisez le mode effectif, pas un seul champ

Il existe trois modes : désactivé, strict et souple. Le strict impose une attente de route différente du souple, et le réglage global interagit avec ceux de chaque interface, si bien que lire un seul fichier peut mal décrire ce qui est réellement en vigueur. Lisez les deux, et lisez-les sur l'interface qui reçoit la réponse, pas sur celle de la route par défaut.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

La recherche de route de cette troisième ligne est la partie que les gens sautent. Elle vous dit ce que le noyau croit de la source, et c'est exactement l'entrée de la vérification.

Trouvez l'incohérence avant de changer la vérification

Déterminez pourquoi la réponse arrive sur cette interface et si sa route inverse est censée différer. Une règle de politique qui envoie les requêtes par un chemin tandis que les réponses reviennent par un autre est une conception légitime, et c'est aussi la conception que la validation stricte rejette. Les marques utilisées dans le routage par politique peuvent compter ici aussi, car elles changent ce que renvoie la recherche inverse.

Si la route inverse manque simplement, l'ajouter corrige la cause au lieu de désactiver une vérification. Une route manquante, un rejet du pare-feu et un sélecteur de trafic erroné produisent le même symptôme visible, et un seul d'entre eux concerne la validation de source.

Ne désactivez pas les contrôles de source globalement comme première réaction. Cela échange un diagnostic précis contre un changement de comportement large dont vous devrez vous souvenir plus tard.

Un ajustement sélectif que vous pouvez défendre

Si un ajustement étroit est vraiment nécessaire, limitez-le à l'interface qui en a besoin, notez pourquoi, et placez-le dans la configuration qui possède cette interface afin qu'il survive à un redémarrage. Retestez ensuite exactement le flux qui a échoué, de la même source vers la même destination, plutôt qu'un ping vers quelque chose de pratique.

Incluez un cas qui devrait toujours être refusé. Si ce cas réussit désormais, l'ajustement a affaibli plus que le seul chemin que vous vouliez réparer.

Gardez IPv4 et IPv6 séparés

Un sysctl d'apparence familière n'est pas une politique pour chaque famille d'adresses. IPv6 a son propre comportement et ses propres réglages, et une machine peut être stricte sur une famille et permissive sur l'autre sans que personne ne le remarque avant qu'une destination précise n'échoue. Vérifiez les deux si la charge de travail utilise les deux.

Consignez le mode, l'interface, la sortie de la recherche de route et la raison du changement au même endroit. La personne suivante trouvera le réglage et aucune explication, et soit le supprimera, soit le copiera là où il n'a rien à faire.