O NAT usa uma combinação de número de porta de endereço IP para fazer o hash dos pedidos de saída. Como as solicitações de ping consistem em pacotes de solicitação de eco ICMP, elas não possuem nenhum número de porta associado. Como um servidor NAT encaminha as respostas para os hosts dentro da rede?
Respostas:
Para mensagens do tipo consulta / resposta ICMP, como Echoes (pings), o NAPT usa o ID de consulta ICMP (às vezes chamado apenas de ID ICMP) da mesma maneira que usaria um número de porta TCP ou UDP.
Para mensagens de erro do ICMP, como Destino inacessível, ele usa a cópia interna do pacote ICMP dos cabeçalhos do quadro que causou o erro para descobrir qual mapeamento na tabela NAT usar para convertê-lo.
Esses procedimentos são mencionados brevemente em várias RFCs relacionadas à NAT, mas tive dificuldade em encontrar uma que explicitasse explicitamente o procedimento. Veja "NAT Tradicional", RFC3022 , seção 4.1.
Isso não entra em conflito com nenhum mapeamento TCP ou UDP, porque em uma boa implementação do NAPT, o protocolo é uma das informações mantidas na entrada da tabela NAT para torná-lo exclusivo.
Fiz uma pequena simulação (baseada no dispositivo CLI GSN3 Kali Linux), para verificar o que acontece quando o ICMP entra em conflito (aparentemente, pode ser específico do fornecedor):
Em solicitações / resposta de ICMP Antes que a NAT seja exibida, a situação, quando os identificadores de solicitações de ICMP de 2 dispositivos (com IPs 10.0.0.1 e 10.0.0.2 respeitosamente) se tornam iguais.
Ao mesmo tempo, em solicitações / resposta de ICMP Depois que o NAT é mostrado, o identificador da sessão do ICMP em conflito é alterado para 0 pelo NAT e é incrementado a partir daí.
Como um resumo, pode-se dizer que o NAT do Linux lida com o choque de identificadores de ICMP (como os identificadores de ICMP não são alterados antes do NAT).