NAT utilise une combinaison de numéros de port d'adresse IP pour hacher les requêtes sortantes. Étant donné que les requêtes ping se composent de paquets de demande d'écho ICMP, ils n'ont aucun numéro de port associé. Comment un serveur NAT transmet-il les réponses aux hôtes à l'intérieur du réseau?
Réponses:
Pour les messages de type requête / réponse ICMP comme 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 provoqué l'erreur pour déterminer le mappage dans la table NAT à utiliser pour le traduire.
Ces procédures sont référencées brièvement dans plusieurs RFC liés à NAT, mais j'ai eu du mal à en trouver une qui expliquait explicitement la procédure. Voir «NAT traditionnel», RFC3022 , section 4.1.
Cela n'entre 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 les conflits ICMP (apparemment, cela pourrait être spécifique au fournisseur):
Sur les demandes / réponses ICMP Avant que NAT ne soit affiché, la situation, lorsque les identifiants des demandes ICMP de 2 périphériques (avec les IP 10.0.0.1 et 10.0.0.2 respectivement) deviennent égaux.
Dans le même temps sur les demandes / réponses ICMP Après NAT, il est montré que l'identifiant de la session ICMP en conflit est changé à 0 par le NAT et est incrémenté à partir de là.
Pour résumer, on peut dire que le NAT Linux gère le conflit des identifiants ICMP sur son (Comme les identifiants ICMP ne sont pas modifiés avant le NAT).