Route VPN ou règle de pare-feu : laquelle laisse tomber le paquet ?

Deux décisions indépendantes portent sur le même paquet, et l’une comme l’autre peut mettre fin à la requête en silence. La recherche de route choisit une interface et un saut suivant, puis le filtre de paquets décide si cette combinaison est autorisée. Un délai d’expiration vous dit que l’une des deux a refusé, pas laquelle. Suivez les étapes dans l’ordre et la réparation cesse généralement d’être une devinette.

Deux décisions, un paquet, deux propriétaires

La recherche de route consulte d’abord les règles de politique, puis la table vers laquelle elles pointent, et choisit le préfixe le plus spécifique qui correspond à la destination. Un client qui a installé une route de tunnel possède cette décision, et rien dans une règle de pare-feu ne peut la remplacer. Quand la recherche pointe vers un endroit inattendu, chaque étape suivante travaille sur le mauvais paquet.

Le filtrage est distinct. Sur un hôte Linux, les crochets netfilter répartissent le trafic selon le destinataire du paquet : la sortie quitte la machine, l’entrée s’y termine, le transfert la traverse. Une passerelle qui accepte des clients VPN et les route vers un LAN a besoin du chemin de transfert, et c’est exactement la chaîne que la plupart des configurations par défaut laissent vide.

La sélection de la source relève de la même décision, et c’est là que se cachent la plupart des décalages. Le noyau choisit une adresse source sur l’interface sortante, sauf si la route en nomme une, si bien qu’une règle de filtre écrite pour le sous-réseau LAN ne correspond jamais à un paquet sortant avec l’adresse du tunnel.

Lisez ce que la recherche a réellement choisi

Affichez la décision au lieu de la déduire. La commande ci-dessous résout la route que le noyau utiliserait pour cette destination, y compris l’interface et la source qu’il choisirait :

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

Les clients VPN installent souvent des règles de politique à des priorités inférieures à la table principale, donc une table principale propre ne prouve rien en soi. Comparez les priorités des règles avec les tables qu’elles sélectionnent, et vérifiez si la route du tunnel survit à une reconnexion au lieu d’être ajoutée à la main une seule fois.

L’IPsec basé sur la politique ajoute une troisième étape de correspondance que le routage ne couvre pas, comme le décrivent les notes de transfert de strongSwan pour les configurations tunnel et transport. La politique de sécurité sélectionne le trafic par préfixe et protocole, tandis que la route décide seulement où irait un paquet non protégé. Un sous-réseau routé mais sans sélecteur correspondant reste soit non protégé, soit rejeté, selon la configuration, et aucun des deux résultats ne ressemble à un problème de pare-feu. Affichez la politique et comparez ses sélecteurs aux préfixes que vous attendiez du tunnel.

Le filtrage s’applique à un crochet, pas à une route

Une règle qui autorise l’écouteur VPN est une règle sur le trafic adressé à la passerelle elle-même. Elle ne dit rien des clients qui atteignent des hôtes derrière cette passerelle, car le trafic transféré traverse une autre chaîne. Lire l’ensemble des règles comme une liste plate est la raison habituelle pour laquelle une règle d’apparence correcte ne se déclenche jamais.

Les compteurs tranchent vite la question. Une règle dont le compteur de paquets est nul n’a jamais été atteinte, ce qui désigne la mauvaise chaîne, la mauvaise interface ou un rejet antérieur. Une règle dont le compteur augmente sous une politique de rejet est la frontière que vous cherchiez, et le paquet est écarté plutôt que mal routé.

Envoyez une sonde par le chemin qu’utilise le client

Les tests exécutés sur la passerelle elle-même passent par la sortie et l’entrée, avec l’adresse source de la passerelle. C’est un chemin différent de la requête transférée d’un client, donc un curl local réussi prouve moins qu’il n’y paraît. Testez depuis la machine qui échoue, ou fixez explicitement l’interface et la source.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Une capture aux deux extrémités sépare les cas restants. Un SYN qui quitte le client et n’arrive jamais signifie routage, chiffrement ou liste d’accès en amont. Un SYN qui arrive et ne reçoit pas de réponse signifie le service ou son filtre d’hôte, et le tunnel n’a jamais été le problème.

Le trafic de retour mérite son propre examen. Le routage asymétrique plus le filtrage de chemin inverse écartent les réponses qui arrivent sur la mauvaise interface, ce qui se manifeste comme une connexion unidirectionnelle plutôt qu’un port bloqué. Vérifiez la valeur sysctl avant d’accuser le pare-feu d’un symptôme qu’il n’a pas causé.

La journalisation sert de second avis, pas de première étape. Une instruction de journal temporaire sur la chaîne de transfert nomme l’interface et les adresses qui l’ont frappée, et elle est facile à retirer ensuite. Laissez-la en permanence et vous avez bâti un problème de volume de journaux au lieu d’une réponse.

Placez chaque changement là où il survit à une reconnexion

Une route ajoutée avec ip route add vit jusqu’à ce que l’interface tombe. Persistez-la plutôt dans le profil de connexion : NetworkManager accepte des routes supplémentaires sur la connexion, et netplan les conserve entre les démarrages. La même règle vaut pour une exception de pare-feu côté client, qui disparaît après le prochain rechargement.

Les règles côté serveur appartiennent au fichier de configuration que le service charge au démarrage, pas à une session interactive qui se termine quand vous la fermez. Écrivez la règle, rechargez et confirmez que le compteur a bougé, car un rechargement qui a rejeté la syntaxe laisse silencieusement l’ancien jeu de règles en place.

Répétez ensuite la requête d’application d’origine de bout en bout et notez quelle couche a changé. Une correction de route qui exigeait aussi un changement de filtre échouera encore, et le second échec se lit bien plus facilement une fois que vous savez que le premier a disparu. Notez la date et la version du client à côté du résultat, car les valeurs par défaut de routage et de filtrage bougent toutes deux entre les versions. Gardez cette note sur le ticket pour que la personne suivante commence là où vous vous êtes arrêté au lieu de refaire le parcours en deux étapes.