Pourquoi un client VPN sur le LAN du bureau perd chaque réponse

Un portable est sur le /24 du bureau via Ethernet et rejoint aussi un serveur OpenVPN qui vit dans ce même /24. Un collègue fait un ping vers l’adresse du tunnel ; la requête arrive clairement, et rien ne revient. Le journal du tunnel est propre et la navigation fonctionne encore, donc le tunnel est le mauvais suspect. La validation de source IPv4 sur la machine qui reçoit jette le paquet avant que quoi que ce soit le lise.

Le rejet se produit avant que quoi que ce soit lise le paquet

La validation de source pose une question sur chaque paquet entrant : si cet hôte répondait à cette source, la réponse sortirait-elle par l’interface par laquelle le paquet vient d’arriver ? Quand la réponse est non, le noyau jette le paquet à l’arrivée. Ni une socket ni un chemin de transfert ne le voient jamais, et c’est pourquoi une capture sur le tunnel enregistre encore une requête que l’application ne reçoit jamais.

Le client ici détient 10.66.0.9 sur son tunnel, et le serveur OpenVPN répond à 192.168.80.10 dans le préfixe du bureau. Un collègue à 192.168.80.25 fait un ping vers l’adresse du tunnel, donc la requête traverse le LAN, le serveur l’achemine dans le tunnel, et elle arrive sur l’interface tunnel du client en portant une adresse source du bureau. Dans la table de routage de cette machine, le préfixe du bureau appartient à l’appareil Ethernet, pas au tunnel. La validation compare l’interface d’arrivée à la route, trouve une incohérence et écarte le paquet, si bien que le collègue voit une perte totale alors que les deux extrémités annoncent un tunnel sain.

La direction miroir a la même forme : quand le client initie vers le bureau, les réponses peuvent être écartées côté bureau pour la même raison. Un correctif vérifié dans un seul sens revient généralement comme un second ticket.

Prouvez le mode en vigueur avant de toucher à un sysctl

Lisez les valeurs effectives plutôt que de vous fier à un défaut de distribution, car le réglage par interface n’est que la moitié de la décision. Le mode en vigueur est le plus élevé entre la valeur de l’interface et la valeur d’all, donc un zéro sur l’interface du tunnel ne signifie rien tant que all vaut un. La décision du mode strict est une décision de routage, donc exécutez la recherche que le noyau exécute et comparez sa réponse à l’interface par laquelle le paquet est réellement arrivé.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Répétez ensuite le ping en surveillant le compteur d’erreurs. Un compteur qui monte à côté d’une requête que la capture montre déjà est la signature de ce rejet, pas celle d’une route absente. Activez la journalisation des paquets martiens pendant que vous y êtes, pour que le noyau nomme la source et l’interface qu’il a rejetée. Ensemble, ils écartent le chiffrement, le pare-feu et un iroute manquant comme explications.

Notez la référence avant de changer quoi que ce soit : les deux valeurs, l’appareil choisi par la recherche et le compteur que vous avez surveillé. C’est cet enregistrement qui vous dira ensuite si le changement a fait ce que vous croyez.

Ce que chaque mode de rp_filter accepte réellement

Le noyau expose trois valeurs par interface, et ce ne sont pas trois nuances d’une même règle. Zéro désactive le contrôle. Un est strict et exige que la source soit routée vers l’interface d’arrivée. Deux est laxiste et exige seulement qu’une route vers la source existe dans la table, où qu’elle pointe.

La ligne qui compte ici est la laxiste, et ce qu’elle continue de rejeter. Une source falsifiée routable n’importe où dans votre table passe, tandis qu’une source sans aucune route est toujours refusée. Sur un portable, c’est une concession étroite ; sur un routeur qui transfère le trafic d’autres personnes, elle est large. Le mode appartient à l’hôte, donc le même chiffre porte un poids différent aux deux endroits.

La ligne dont cette topologie a besoin découle de la table et non de l’habitude. Le paquet est légitime et sa source est routable, donc le laxiste l’accepte et le strict non. Rien dans ce cas n’exige zéro, et choisir zéro retirerait un contrôle qui ne coûte rien ici.

Choisissez le plus petit changement qui supprime l’ambiguïté

Le mode laxiste est le plus petit changement qui convient, et c’est une vraie réduction de la rigueur, pas un interrupteur anodin. Une meilleure option existe dès que la topologie le permet : supprimez le chevauchement, et l’ambiguïté disparaît.

Là où le préfixe du bureau n’est nécessaire que par Ethernet, retirez-le des routes que le profil tire et l’adresse devient joignable par un seul chemin. Quand les deux chemins doivent vraiment coexister, épinglez la source et l’appareil avec une règle de politique au lieu d’assouplir la validation sur chaque interface. Cela garde un filtrage strict pour tout le reste de la machine et documente l’exception là où le prochain ingénieur la cherchera.

Quel que soit le chemin choisi, consignez-le dans un drop-in sysctl plutôt que dans une commande vivante. Réglez les clés all et default ensemble, pour qu’une reconnexion ne puisse pas rétablir silencieusement le mode strict.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Ce que le mode laxiste abandonne, et où

Le mode laxiste rejette encore une source qu’aucune route ne pourrait atteindre, et il cesse de rejeter une source falsifiée qui se trouve être routable. Sur un portable, c’est une concession étroite. Sur un appareil qui transfère un trafic qu’il ne possède pas, le même choix est bien plus large. Le même réglage porte donc deux significations très différentes selon l’endroit où il s’exécute.

Couper complètement le contrôle sur un hôte qui transfère le trafic d’autres personnes est la seule réparation à éviter. Zéro jette la validation que le mode laxiste prend soin de conserver. Si l’hôte transfère pour d’autres, défendez plutôt l’option de la règle de politique de la section précédente.

Laissez une note nommant les deux interfaces, le préfixe qui se chevauche et la sonde exacte qui réussit maintenant. C’est plus utile au prochain ingénieur qu’une ligne disant que le filtrage a été ajusté.