Comment un serveur NAT transfère-t-il les paquets de réponse d'écho ICMP ping aux utilisateurs?
Pour les messages de type requête/réponse ICMP tels que Echoes (pings), NAPT utilise l'ID de requête ICMP (parfois simplement appelé ID ICMP) de la même manière qu'il utiliserait un numéro de port TCP ou UDP.
Pour les messages d'erreur ICMP tels que Destination inaccessible, il utilise la copie interne du paquet ICMP des en-têtes de la trame qui a permis à l'erreur de déterminer quel mappage dans la table NAT utiliser pour la traduire.
Ces procédures sont brièvement référencées dans plusieurs RFC liées au NAT, mais j’ai eu du mal à en trouver un qui énonce explicitement la procédure. Voir "NAT traditionnel", RFC3022 , section 4.1.
Cela n'entre pas en conflit avec aucun mappage TCP ou UDP car, dans une bonne implémentation NAPT, le protocole est l'une des informations contenues dans l'entrée de table NAT pour le rendre unique.
J'ai fait une petite simulation (basée sur l'appliance CLI GSN3 Kali Linux), pour vérifier ce qui se passe lorsque des conflits ICMP se produisent (apparemment, cela pourrait être spécifique au fournisseur):
On demandes/réponses ICMP avant NAT indique la situation lorsque les identifiants des demandes ICMP provenant de 2 périphériques (avec les adresses IP 10.0.0.1 et 10.0.0.2) deviennent égaux.
En même temps sur demandes/réponses ICMP après NAT , l'identifiant de la session ICMP en conflit est modifié en 0 par le NAT et est incrémenté à partir de là.
En résumé, on peut dire que Linux NAT gère le conflit d'identificateurs ICMP lorsqu'il est activé (car les identificateurs ICMP ne sont pas modifiés avant le NAT).