Le NAT source masque les adresses des clients à un pare-feu ultérieur

Une règle écrite pour les clients du personnel et du laboratoire est déployée sur le nouveau pare-feu de bord, et elle correspond silencieusement à tout ou à rien. La raison se situe en amont : une passerelle a déjà réécrit les adresses des clients, si bien que la règle voit une seule adresse de transit au lieu de deux groupes. Ajouter un équipement ne restaure pas l'information que le chemin a supprimée. Trouvez le dernier point où la distinction existe encore avant d'écrire la politique.

Pourquoi la règle de bord ne voit qu'une adresse

La traduction plusieurs-à-un associe chaque couple interne adresse et port à une adresse externe partagée avec un port attribué. Les conversations restent distinguables pour le traducteur grâce à ces liaisons de port, mais un équipement en aval qui effectue une simple correspondance de préfixe source ne voit que l'adresse partagée. Cela suffit à rendre deux groupes identiques au niveau de la règle. Les paquets arrivent toujours ; le regroupement, non.

Vérifiez ce que l'interface du pare-feu observe réellement, et non ce que le schéma promet. Les deux diffèrent plus souvent qu'on ne l'attend.

Trouvez la dernière identité applicable

Partez du point d'application et remontez jusqu'à ce que le préfixe d'origine apparaisse. Deux commandes localisent généralement la frontière.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

La table NAT indique quel trafic est traduit et par quelle règle, tandis que la liste conntrack montre les tuples d'origine et traduits des flux actifs. Là où le pare-feu amont ne voit jamais que l'adresse traduite, des règles source par groupe ne peuvent pas y fonctionner, quelle que soit leur écriture. Avancez ou reculez le long du chemin jusqu'à un équipement où les deux préfixes clients restent distincts. Notez la source à chaque saut au lieu de vous fier à une étiquette intérieure ou extérieure.

Trois emplacements et leur coût

La politique peut vivre sur la passerelle qui traduit, où les sources d'origine restent visibles. Elle peut vivre sur le pare-feu amont si le transit devient routé plutôt que traduit, ce qui suppose d'ajouter des routes de retour et de supprimer la réécriture de source. Ou elle peut être appliquée sur l'identité plutôt que sur les adresses, via un contrôle authentifié qui connaît l'utilisateur ou l'appareil. Chaque choix a un propriétaire et un mode de défaillance, et seuls les deux premiers gardent la règle purement liée aux adresses source.

Quel que soit votre choix, documentez la règle avec l'adresse à laquelle elle correspond. Une règle dont l'hypothèse d'adresse a changé silencieusement est pire qu'aucune règle, car elle continue de correspondre au trafic tout en protégeant quelque chose de tout autre.

Acceptation : un client autorisé et un client refusé

Testez avec une paire de clients, un de chaque groupe, et capturez comment chacun arrive au point d'application. Conservez les deux tuples à côté du résultat de la règle, afin que la preuve montre que la distinction a survécu et non qu'un autre pare-feu existe. Répétez le test après un changement de NAT ou de routage, car l'adresse présentée est la partie qui casse silencieusement. Maintenez l'authentification partout où des personnes doivent être distinguées, car une adresse source est une entrée de politique, non une preuve d'identité.

Inscrivez le point d'application, la source observée et la règle dans le ticket. Sinon, l'ingénieur suivant ajoute un second pare-feu et la même règle.