Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

NAT : coupure de connexion ou pas en cas de bascule ?

Bonjour, J'ai 2 routeurs avec les mêmes règles de NAT statique sans synchronisation des tables de session et du routage dynamique de chaque côté. R1 est le primaire. En cas de problème sur R1, le trafic est rerouté sur R2 dans les sens. Ma question est : est-ce les connexions TCP déjà ouvertes doivent être réétablies ? D'après moi : non. La seule action qui peut être nécessaire en couche 4 est le recalcul du checksum avec l'IP translatée. C'est aussi ce qui permet, par exemple, à IPSEC / ESP / tunnel de passer à travers. Sauf que quand on regarde la table de translation d'un routeur Cisco, on voit qu'une entrée est créée pour les nouveaux flux. D'après les tests d'un collègue, il y a coupure lors des bascules. J'ai l'impression que le suivi de connexion n'est pas nécessaire mais quand même effectué. Ce lien semble confirmer ma théorie : http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftsnat.html#wp1040059 Quelqu'un d'autre me dit que ça dépend de la connexion... Merci !

Les adresses IP natées sont elles les mêmes de chaque coté ? Si ce n'est pas le cas, je ne vois pas comment les connexions pourraient être maintenues sans une synchro spécifique au niveau du matériel, vu qu'une connexion TCP est établie spécifiquement entre deux adresses IP. Si jamais c'est la même IP publique qui est partagée, cela pourrait marcher vu que le routeur va encapsuler le traffic TCP sans se soucier du contenu et donc des ports ou des numéros de séquence/acquittement. Sur le papier ça a l'air de rouler, mais quid de la réalité ?

Les IP de NAT sont les mêmes de chaque côté. Donc, sur papier, on est tous les 2 d'accord. Dans la réalité, on cherche justement à savoir s'il faut ou pas incriminer le NAT. Le NAT est un bon suspect actuellement mais je ne suis pas convaincu des explications qu'on m'a fournit jusqu'à présent. Pour moi, l'équipement regarderait justement les ouvertures de connexion alors qu'il n'en a pas besoin. Le fait qu'il s'en mêlerait nous pose des problèmes. Donc, quelles sont les raisons qui pour lesquelles il y aurait besoin d'inspecter la couche 4 pour une translation statique ?

Effectivement, parce que la NAT serait mal implémentée. Je pencherais là dessus car la NAT statique se contente de fonctionner en couche 3, donc pas de problème a priori. Cependant, il est fort possible que les implémentations soient... originales et prennent en compte des critères supplémentaires qu'elles ne devraient pas (genre les ports...) C'est un problème intéressant 😀

😀 On est du même avis ! ^^ Je te tiens au courant des résultats de l'enquête.

D'après mon founirsseur, la NAT statique, dans mon cas, n'engendre pas de création de session. Le test avec une connexion TCP (Telnet) lors d'une bascule n'a pas engendré de fermeture et de réouverture de connexion. Ce qui peut arriver : - Création de session en couche IP en cas de fragmentation. - Si des inspections applicatives de type ALG sont nécessaires, cela peut nécessiter un suivi de connexion TCP et donc une synchronisation des tables de NAT. - Si le temps de convergence est supérieur à 1s, risque de planter certaines implémentations de TCP (d'après le fournisseur). - Si le temps de convergence est supérieur à 1s, risque de connexions half-open si le flux est unidirectionnel (d'après moi).