Dentro de um computador, entre processos
Primeiro, vamos ver como um computador único distingue entre conexões simultâneas.
A maioria dos protocolos de transporte, como TCP, UDP, SCTP , usam duas portas, origem e destino , ou seja, um em cada extremidade da conexão. Ou seja, os pacotes não simplesmente andam "por" uma porta; em vez disso, eles viajam da porta X para a porta Y
.A porta destination é geralmente bem conhecida (80 para HTTP, 53 para DNS…) mas a porta source é geralmente escolhida aleatoriamente pelo próprio SO, que também garante que a combinação src / dst seja única.
Assim, quando o seu navegador faz múltiplas conexões "para a porta 80 do Yahoo", todas elas têm diferentes portas de origem , e o SO mantém uma tabela de socket como:
PROCESS PROTO LOCAL REMOTE STATE
9894/firefox tcp 192.168.6.175:39163 google.server:80 established
9894/firefox tcp 192.168.6.175:52909 yahoo.server:80 established
17463/chrome tcp 192.168.6.175:64981 yahoo.server:80 established
9894/firefox udp 192.168.6.175:4984 8.8.8.8:53 --
Assim, quando o sistema operacional recebe um pacote TCP de yahoo.server:80 para a porta local 52909, ele pode mapeá-lo para a conexão específica feita pelo Firefox.
Importante notar que isso não tem nada a ver com o NAT ainda , e acontece da mesma maneira mesmo se você estiver conectado diretamente. (NAT fará uso disso, no entanto.)
(Você pode ver essa tabela usando netstat -n ou várias ferramentas gráficas no Windows. Muitas vezes, "local / remoto" são rotulados como "origem / destino", embora isso não seja inteiramente exato.)
Dentro de uma rede NATed, entre computadores
A resposta à sua pergunta sobre o NAT é muito semelhante, apenas tudo é feito em uma escala maior.
O roteador que executa o NAT mantém uma tabela de "estado" contendo os endereços interno e externo & portas. Por exemplo, se suas duas solicitações HTTP usassem conexões TCP separadas, elas poderiam ser rastreadas como:
PROTO ORIG-SRC ORIG-DST REPLY-SRC REPLY-DST
6/tcp 192.168.6.42:52909 yahoo.server:80 yahoo.server:80 your.public.ip.addr:52909
6/tcp 192.168.6.175:39163 yahoo.server:80 yahoo.server:80 your.public.ip.addr:39163
6/tcp 192.168.6.175:52909 yahoo.server:80 yahoo.server:80 your.public.ip.addr:28330
17/udp 192.168.6.175:4984 8.8.8.8:53 8.8.8.8:53 your.public.ip.addr:4984
Quando o roteador recebe um pacote do REPLY-SRC (Yahoo) endereçado para o REPLY-DST (seu endereço IP público), ele sabe que o destino real deve ser obtido da coluna ORIG-SRC a fim de desfazer o NAT.
(Se não houver um estado correspondente, as regras de encaminhamento de porta configuradas manualmente serão processadas. Se ainda não houver nenhuma correspondência, o pacote foi realmente destinado ao próprio roteador.)
Observe como a tabela de estados contém endereços e ports , permitindo que várias conexões ao mesmo servidor sejam diferenciadas pela combinação de portas. No meu exemplo, dois computadores usaram acidentalmente a mesma combinação de portas, então a segunda conexão também teve suas portas traduzidas.
(Na verdade, alguns NATs parecem somente na porta e ignoram completamente o endereço de origem; isso reduz o número de conexões possíveis, mas torna muito mais fácil para os programas ponto-a-ponto realizar "perfuração de furos NAT".)
Esse estado é mantido mesmo para protocolos sem conexão, como UDP ou ICMP; portanto, as entradas expiram após algum intervalo de inatividade, mesmo que não exista um pacote "conexão próxima" explícito. (A tabela de estados é, na verdade, parte do firewall, portanto, mesmo que o NAT não esteja pronto, o roteador ainda poderá usá-lo para distinguir entre conexões "ativas" e pacotes dispersos).
(Se o seu roteador é baseado em Linux, conntrack -L ou cat /proc/net/nf_conntrack mostraria esta tabela. Para o OpenBSD ou pfSense, tente pfctl -s state .)