Résumé

  • L’exigence REQ-7 de la RFC 5382 interdit à un traducteur d’adresses d’attribuer simultanément la même association adresse-port à plusieurs terminaux internes pour TCP.
  • L’économie apparente ne devient visible comme faute que lorsque deux titulaires cachés contactent la même adresse et le même port externes : leurs quadruplets publics se confondent et le retour ne possède plus de destinataire unique.

Le faux acte de propriété

Sur Internet, une adresse IPv4 publique et un port TCP ne constituent pas une identité civile. Ils forment néanmoins, pendant la durée d’une association, une coordonnée utilisable. Le serveur distant renvoie ses segments vers elle. Les journaux d’exploitation l’emploient pour relier une observation externe à un état interne. Une application peut la communiquer à un pair. Toute cette mécanique suppose qu’au même instant et dans le même protocole, la coordonnée conduit à un titulaire déterminé.

La surcharge de ports rompt cette hypothèse. Le traducteur donne la même adresse et le même port externes à deux couples internes différents. Pour préserver la distinction, il ajoute en secret la destination distante à sa clé de recherche. Le premier terminal parle au serveur X, le second au serveur Y : la table sait encore choisir. Le gain semble réel, car un seul port public sert deux flux.

Mais X et Y ne sont pas des propriétés des titulaires. Ce sont des circonstances. Si les deux terminaux se tournent ensuite vers le même grand service, avec la même adresse et le même port de destination, la circonstance distinctive disparaît. Les deux connexions présentent le même quadruplet au monde extérieur. Le port n’avait pas créé de capacité supplémentaire ; il avait emprunté une différence qui n’était pas garantie.

La section 7.1 de la RFC 5382 décrit exactement ce cas. Deux terminaux internes partageant la même association ne peuvent établir simultanément des connexions vers un même terminal externe. REQ-7 en tire une règle normative : un NAT ne doit pas pratiquer la surcharge de ports pour TCP.

Réutiliser pour un titulaire, partager entre titulaires

La nuance est essentielle parce que la même RFC exige aussi une association indépendante du terminal distant. Une application interne doit pouvoir conserver son association externe lorsqu’elle dialogue avec plusieurs destinations. Ce comportement évite que son identité publique change au gré de chaque interlocuteur.

Il ne faut pas en déduire que l’association est disponible pour d’autres applications internes. La réutilisation par le même couple interne assure une continuité. Le partage entre couples internes crée une copropriété. Dans le premier cas, plusieurs destinations observent le même titulaire. Dans le second, plusieurs titulaires portent la même projection publique et ne restent séparés que par les destinations.

Une documentation qui se contente de dire « réutilisation activée » masque donc la décision la plus importante. Qui réutilise quoi ? Pendant quelle durée ? La clé externe reste-t-elle singulière pour un couple interne ? La destination distante est-elle devenue une partie indispensable de l’identité ?

La politique de filtrage est encore une autre question. Elle détermine quelles sources externes peuvent utiliser une association existante. Une analyse BTW distincte traite déjà du fait qu’une association NAT64 n’est pas une politique de filtrage. Ici, le jugement intervient en amont : avant d’autoriser un paquet, le traducteur sait-il à quel titulaire unique il doit l’offrir ? Une permission bien définie ne répare pas un nom ambigu.

La collision n’est pas l’ouverture simultanée

La RFC 5382 est souvent citée pour l’ouverture simultanée de TCP. Dans ce mécanisme, deux pairs émettent chacun un SYN, les segments se croisent et la machine d’états permet l’établissement d’une seule connexion. Une autre étude BTW possède déjà cette histoire et la fenêtre de six secondes imposée aux traducteurs.

La surcharge met en scène d’autres acteurs. Deux applications placées derrière le même traducteur ne cherchent pas nécessairement à se joindre. Elles contactent un troisième service commun. Le traducteur les a projetées sur une seule source publique. La collision ne provient donc ni de SYN croisés, ni d’une inversion des rôles client et serveur. Elle provient d’une allocation qui a supprimé la différence entre deux demandeurs.

Cette séparation guide le diagnostic. Pour une ouverture simultanée, on examine les transitions SYN-SENT, SYN-RECEIVED et la politique appliquée au SYN entrant. Pour une surcharge, on examine les reçus d’allocation : couples internes, association externe, destination, horodatage, version de la politique et nœud propriétaire. Employer le même mot « échec NAT » pour les deux cas ferait perdre la décision qui doit être corrigée.

La rareté ne confère pas un droit de compression

Le motif économique est sérieux. Une adresse IPv4 publique coûte cher. Les opérateurs doivent servir un nombre croissant de terminaux avec des pools finis. Les fournisseurs publient des densités de sessions, des vitesses d’allocation et des tailles maximales de table. Dans cet univers, un port inutilisé ressemble à une ressource gaspillée.

Or TCP ne consomme pas un numéro isolé. Une connexion associe deux extrémités, des numéros de séquence, un état et un chemin de retour. L’association externe est une créance temporaire sur le traducteur : tant qu’elle existe, les paquets qui lui sont adressés doivent rejoindre le bon couple interne. Réduire le nombre de ports employés n’est un progrès que si cette promesse reste vraie.

Lorsque le pool est épuisé, le choix honnête peut être de refuser une nouvelle connexion. Ce refus révèle la contrainte et protège les associations existantes. La surcharge produit un résultat plus séduisant dans les premières millisecondes : la demande est admise. Mais elle rend possible un échec silencieux dès que les destinations convergent. Un compteur d’admission vert peut ainsi cacher une dette d’identité.

La gouvernance de capacité doit compter les refus, les files d’attente, les durées de rétention et l’usage des blocs de ports. Elle ne doit pas transformer une exigence d’unicité en variable d’ajustement. La rareté autorise la planification et le contrôle d’admission ; elle n’autorise pas la fabrication de deux titulaires sous le même titre.

Le détour intérieur confirme l’attente extérieure

REQ-8 exige le hairpinning TCP : deux terminaux internes qui ne se connaissent que par leurs adresses externes doivent pouvoir communiquer, et le paquet renvoyé à l’intérieur doit présenter comme source l’adresse et le port externes de l’émetteur. Ce détail montre ce que l’application attend. Elle ne veut pas seulement recevoir des octets ; elle veut les associer au pair qu’elle a choisi.

Le hairpinning et l’interdiction de surcharge ne sont pas la même exigence. Ils protègent cependant la cohérence du même vocabulaire. L’un maintient l’identité externe sur un chemin qui revient à l’intérieur. L’autre empêche cette identité d’être simultanément prêtée à plusieurs sources internes.

Un système peut fonctionner dans un laboratoire où chaque client contacte une destination différente. Il peut également réussir après une simple bascule si le nœud de secours reçoit toute la clé cachée. Rien de cela ne prouve que la coordonnée est correctement gouvernée. Le test décisif est convergent : deux sources internes, une destination externe, associations actives au même instant.

Les messages d’erreur ne possèdent pas la connexion

Les exigences voisines de la RFC fournissent une autre leçon de périmètre. Le NAT devrait traduire les messages ICMP Destination Unreachable utiles à TCP, mais la réception d’un message ICMP ne doit pas supprimer l’association ou la connexion. Une indication d’erreur décrit un événement. Elle n’obtient pas, par sa seule présence, l’autorité de détruire l’état.

Il en va de même pour l’inactivité. La RFC prévoit des durées minimales lorsque le traducteur ne peut déterminer si les extrémités sont actives. L’article BTW sur TCP keepalive possède l’analyse de ce silence ambigu. Pour la surcharge, le principe utile est plus restreint : une association encore vivante ne devient pas une ressource libre simplement parce qu’aucun paquet récent n’a été observé.

Les ALG ajoutent enfin une autre dette. Si un traducteur modifie les numéros de séquence, il doit traiter correctement les acquittements sélectifs. Une transformation cachée exige un registre exact. Avant même cette comptabilité, la surcharge poserait une question insoluble : de quel espace de séquence et de quel titulaire ce segment relève-t-il ?

Prouver la singularité

Une case de configuration ne suffit pas. Le test de conformité doit créer la situation que REQ-7 protège. Deux couples internes distincts ouvrent presque simultanément une connexion vers la même adresse et le même port externes. La première association reste active. Les sources traduites doivent être différentes. Si aucune ressource conforme n’est disponible, la seconde tentative doit échouer de manière observable ; elle ne doit pas être admise sous une identité ambiguë.

Le reçu associe le couple interne, le couple externe, le pair distant, le protocole, les heures de création et de suppression, la version de l’algorithme, le nœud du traducteur et l’époque de bascule. Les SYN et leurs réponses prouvent ensuite le comportement du transport. Une requête applicative distincte vérifie que le travail attendu a réellement abouti.

Pour l’attribution, l’adresse et le port publics ne valent qu’avec une fenêtre temporelle et une horloge connues. Si la destination distante est requise pour retrouver le titulaire, cette dépendance doit être déclarée. REQ-7 choisit une meilleure base pour TCP : empêcher que deux titulaires simultanés aient besoin de cette qualification secrète.

Sources