Routez entre LAN privés avant d’ajouter un autre NAT

Deux pare-feu internes, un segment de transit privé et une demande pour laisser quelques hôtes de chaque LAN parler à ceux de l’autre. Le réflexe est de monter un VPN ou d’ajouter une seconde couche de NAT, et les deux réflexes coûtent plus cher que le problème ne le mérite. Le routage ordinaire suffit lorsque trois conditions sont réunies : les plages d’adresses ne se chevauchent pas, les deux côtés peuvent renvoyer le trafic vers l’autre LAN et le segment de transit est déjà suffisamment fiable pour les données. Vérifiez ces trois points avant de concevoir quoi que ce soit, car chacun change la réponse.

Trois conditions qui décident de la conception

La première condition est l’espace d’adresses. Si les deux LAN utilisent le même bloc RFC 1918, le routage ne peut pas les distinguer et la traduction devient inévitable plutôt qu’optionnelle. La deuxième est un chemin de retour : une route de A vers B est inutile si B ne sait pas non plus comment joindre le LAN de A, et la connaissance asymétrique est la raison la plus fréquente pour laquelle une conception routée laisse tomber des réponses en silence.

La troisième est la confiance. Le routage déplace des paquets ; il ne les protège pas. Un segment de transit privé à l’intérieur d’un bâtiment est autre chose qu’une remise à un opérateur ou qu’une liaison qui traverse une dorsale de campus partagée. Si le segment n’est pas fiable, la réponse est un tunnel entre les deux pare-feu, et le plan de routage ci-dessous s’applique toujours à l’intérieur.

C’est seulement quand les trois pointent dans le même sens que la conception simple l’emporte. Quand l’une échoue, corrigez cette condition explicitement au lieu de la masquer par de la traduction, car le NAT cache la panne au lieu de la résoudre.

Bâtissez le plan de routes sur le réseau de transit

Donnez à chaque pare-feu une adresse sur le segment partagé et ajoutez une route précise par LAN distant. Rien d’autre dans la configuration existante n’a besoin de bouger, et en particulier la route par défaut vers internet doit rester exactement là où elle est. Remplacer une route par défaut par le pare-feu homologue enverrait chaque destination sans rapport à travers le transit, ce qui est un changement bien plus important que celui demandé. La documentation pfSense sur le routage statique décrit le même modèle route plus passerelle pour cette plateforme, et le contrôle équivalent existe sur le pare-feu que vous exploitez réellement.

Le pare-feu A dessert 10.30.0.0/24 et le pare-feu B dessert 10.40.0.0/24, les deux adresses de transit étant en 192.0.2.0/24. Chaque hôte du LAN garde son pare-feu local comme passerelle, donc le seul nouvel état est une route de chaque côté. Sur un pare-feu sous Linux, le même plan ressemble à ceci, et le transfert doit être activé, sinon la route se résoudra pendant que le paquet est jeté.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Gardez le filtrage séparé de la traduction

Le routage et la politique sont deux contrôles différents, et c’est sur le second que la plupart des conceptions routées échouent réellement. Autorisez les sources, destinations et services précis à la frontière d’entrée que les paquets traversent vraiment, et rappelez-vous qu’une étiquette d’interface comme WAN est un nom, pas une affirmation sur la confiance. Un port de transit portant du trafic privé peut encore avoir le blocage des adresses privées activé par défaut.

Regardez ensuite la traduction sortante avant de conclure qu’aucun NAT n’a lieu. Des règles sortantes automatiques peuvent réécrire du trafic qui n’était pas destiné à être traduit, ce qui détruit les adresses source dont l’autre côté a besoin pour sa propre politique et ses journaux. Confirmez que les flux retenus conservent leurs adresses d’origine, et laissez tranquilles les règles de traduction internet pour le trafic qui en a encore besoin.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Quand le NAT est la réponse honnête

La traduction mérite sa place lorsque les plages d’adresses se chevauchent vraiment et que la renumérotation n’est pas disponible, ou lorsqu’une politique exige qu’un côté voie une adresse unique plutôt qu’un sous-réseau. Dans ces cas, une mise en correspondance délibérée un-pour-un ou restreinte par ports est une décision de conception aux conséquences connues, pas un contournement.

La conséquence qu’il faut énoncer à voix haute est que l’autre côté ne peut plus voir ni filtrer les sources individuelles. Les journaux s’effondrent sur l’adresse de traduction, la politique par hôte cesse de fonctionner et le dépannage devient une chasse pour savoir quel hôte interne possédait un flux à un instant donné. Si rien de tout cela n’importe pour le trafic concerné, le NAT convient.

Quand le transit lui-même est la mauvaise hypothèse

Si le segment partagé traverse un opérateur, une matrice de commutation partagée ou tout chemin où un tiers pourrait lire le trafic, le routage seul n’est pas une réponse complète. Un tunnel entre les deux pare-feu vous donne la confidentialité et l’authentification du pair, et la table de routage à l’intérieur est la même table que vous auriez écrite sur le transit.

Décidez-le à partir de la question de confiance de la première section, pas d’une habitude selon laquelle les VPN seraient plus sûrs. Un tunnel sur un segment déjà privé ajoute un coût d’exploitation et un mode de panne supplémentaire sans gain, tandis que le routage sur un segment non fiable échange la confidentialité contre une simplicité que vous ne pouvez pas vous permettre. Notez laquelle des trois conditions a motivé le choix, et l’ingénieur suivant n’aura pas à le rediscuter.