Odpowiedzi:
W przypadku komunikatów typu zapytanie / odpowiedź ICMP, takich jak echo (ping), NAPT używa identyfikatora zapytania ICMP (czasami nazywanego po prostu ID ICMP) w taki sam sposób, jak używałby numeru portu TCP lub UDP.
W przypadku komunikatów o błędach ICMP, takich jak Docelowy nieosiągalny, wykorzystuje wewnętrzną kopię pakietu ICMP nagłówków ramki, która spowodowała błąd w określeniu, które odwzorowanie w tabeli NAT ma zostać użyte do przetłumaczenia.
Procedury te są pokrótce omówione w kilku RFC związanych z NAT, ale miałem trudności ze znalezieniem takiej, która wyraźnie określiła procedurę. Patrz „Tradycyjny NAT”, RFC3022 , sekcja 4.1.
Nie koliduje to z żadnym mapowaniem TCP ani UDP, ponieważ w dobrej implementacji NAPT protokół jest jedną z informacji przechowywanych we wpisie tablicy NAT, aby uczynić go unikalnym.
Zrobiłem małą symulację (opartą na urządzeniu CLI Linux GSN3 Kali), aby sprawdzić, co się dzieje, gdy ICMP się zderzy (najwyraźniej może to być specyficzne dla dostawcy):
O żądaniach / odpowiedziach ICMP Przed wyświetleniem NAT sytuacja, w której Identyfikatory żądań ICMP z 2 urządzeń (z IP odpowiednio 10.0.0.1 i 10.0.0.2) stają się równe.
Jednocześnie w przypadku żądań / odpowiedzi ICMP Po tym, jak NAT pokazuje, że identyfikator kolidującej sesji ICMP jest zmieniany na 0 przez NAT i od tego momentu jest zwiększany.
Podsumowując, można powiedzieć, że Linux NAT obsługuje kolizję identyfikatorów ICMP na swoim (ponieważ identyfikatory ICMP nie są zmieniane przed NAT).