VPN de site à site : quel sens a réellement besoin d'une règle ?

Les deux extrémités signalent un tunnel établi, l'agence distante répond depuis la passerelle, et l'application expire toujours pour les utilisateurs d'un côté. Le conseil habituel est d'ajouter une règle de pare-feu dans les deux sens. Parfois c'est juste, parfois cela duplique une règle déjà existante, et parfois c'est la seconde règle qui casse l'état. Le cas applicable dépend de l'endroit où le pare-feu voit le paquet.

Le trafic de retour avec état change le compte

Un pare-feu à états enregistre la requête et admet la réponse sans seconde règle, donc une conception qui n'a besoin que d'une règle est normale. Une liste d'accès sans état n'a pas cette mémoire, et la réponse doit être autorisée explicitement. Les deux sont corrects sur leur propre plateforme, ce qui explique le conflit des conseils.

Lisez la documentation de transfert de la plateforme devant vous et vérifiez si la politique que vous modifiez est à états là où elle voit le paquet. Un refus explicite pour le trafic établi, ou un ordre de règles qui évalue la réponse avant la table d'états, transforme une conception fonctionnelle en énigme. Le nombre de règles est un détail d'implémentation, tandis que l'exigence est que les deux sens d'une conversation autorisée puissent aboutir.

Où le pare-feu voit les paquets déchiffrés

Dans un tunnel basé sur des politiques, le pare-feu peut évaluer le paquet chiffré avant le déchiffrement et le paquet déchiffré ensuite, sur des interfaces différentes. Une règle écrite pour la mauvaise interface est présente, correcte et jamais sollicitée. C'est ainsi qu'un jeu de règles copié d'un déploiement fonctionnel peut échouer sur un matériel identique.

L'IPsec basé sur le routage et la plupart des implémentations modernes présentent une interface de tunnel, si bien que le paquet déchiffré y arrive et que les règles d'interface ordinaires s'appliquent. Confirmez quel modèle le déploiement utilise avant de copier un jeu de règles depuis un guide écrit pour l'autre. L'interface de tunnel est aussi l'endroit à consulter lorsqu'il faut savoir si un paquet a été déchiffré du tout.

Le routage asymétrique brise l'hypothèse

Un pare-feu à états suppose qu'il voit les deux moitiés de la conversation. Si la réponse revient par une autre passerelle, cet équipement n'a aucun état pour la requête et la rejette selon sa propre politique. Le symptôme est une panne unidirectionnelle qu'aucune règle côté émetteur ne peut réparer. Suivez le chemin de la réponse avant de modifier quoi que ce soit.

Vérifiez la route de la réponse avant d'ajouter une règle d'autorisation large des deux côtés. Tout tolérer sur chaque interface masque l'erreur de routage et élargit l'accès en même temps, ce qui est la pire combinaison disponible.

Vérifiez les deux sens avec de vraies adresses source

Testez avec l'adresse que le côté distant observe réellement, car la traduction peut faire qu'une règle source ne corresponde à rien. Lancez la capture sur les deux passerelles en même temps.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Une requête qui apparaît sur la passerelle distante avec une adresse source inattendue explique une règle qui ne correspond jamais, et une réponse qui arrive sur la mauvaise interface explique un décalage d'état. Testez ensuite une destination dans le périmètre approuvé et une en dehors, afin que la limite soit démontrée plutôt que supposée.

Notez l'adresse source après traduction, l'interface qu'a utilisée le paquet déchiffré et la règle qui a correspondu. Ces trois faits répondent au prochain ticket sans répéter toute l'enquête.