Wie leitet ein NAT-Server Ping-ICMP-Echo-Antwortpakete an Benutzer weiter?

NAT verwendet eine IP-Adressen-Portnummernkombination, um die ausgehenden Anforderungen zu hashen. Da Ping- Anforderungen aus ICMP-Echoanforderungspaketen bestehen, ist ihnen keine Portnummer zugeordnet. Wie leitet ein NAT-Server die Antworten an die Hosts im Netzwerk weiter?

Für ICMP-Nachrichten vom Typ "Abfrage / Antwort" wie "Echos" (Pings) verwendet NAPT die ICMP-Abfrage-ID (manchmal auch als ICMP-ID bezeichnet) genauso wie eine TCP- oder UDP-Portnummer.

Bei ICMP-Fehlermeldungen wie "Destination Unreachable" (Ziel nicht erreichbar) wird die interne Kopie des ICMP-Pakets der Header des Frames verwendet, die den Fehler verursacht haben, um herauszufinden, welche Zuordnung in der NAT-Tabelle für die Übersetzung verwendet werden soll.

Auf diese Prozeduren wird in mehreren NAT-bezogenen RFCs kurz verwiesen, aber es fiel mir schwer, eine zu finden, in der die Prozedur explizit beschrieben wurde. Siehe "Traditional NAT", RFC3022 , Abschnitt 4.1.

Dies widerspricht keiner TCP- oder UDP-Zuordnung, da in einer guten NAPT-Implementierung das Protokoll eine der Informationen ist, die im NAT-Tabelleneintrag enthalten sind, um es eindeutig zu machen.

Ich habe eine kleine Simulation (basierend auf der GSN3 Kali Linux CLI-Appliance) durchgeführt, um zu überprüfen, was passiert, wenn ICMP-Konflikte auftreten (anscheinend könnte es herstellerspezifisch sein):

Bei ICMP-Anfragen / -Antworten Vor NAT wird die Situation angezeigt, wenn die IDs von ICMP-Anfragen von 2 Geräten (mit den IPs 10.0.0.1 und 10.0.0.2) gleich sind.

Gleichzeitig wird bei ICMP Requests / Response After NAT angezeigt, dass der Identifier der kollidierenden ICMP-Sitzung vom NAT auf 0 geändert und von da an inkrementiert wird.

Zusammenfassend lässt sich festhalten, dass das Linux-NAT das Zusammenstoßen von ICMP-IDs beim Einschalten behandelt (da die ICMP-IDs vor dem NAT nicht geändert werden).