Normalmente, um NAT manterá o ponto final público de um ponto final local igual para todos os pacotes provenientes dele, tornando assim possível a perfuração de furos UDP. No entanto, alguns NATs mapearão o ponto final local para um ponto final público diferente para cada host diferente para o qual um pacote é enviado, impossibilitando a perfuração UDP.
A única maneira de fazer a perfuração UDP tradicional seria adivinhar o ponto final remoto. Contudo, como existem mais de 65.000 portas, este método não é muito confiável. Então, eu li que aplicativos como o Skype - que são capazes de se comunicar através de praticamente qualquer tipo de NAT - usam um relé para isso. Aqui estão minhas perguntas:
Um relé é simplesmente um soquete que transfere dados recebidos de um soquete para outro, certo? Existem outras maneiras de fazer furos UDP em NATs impertinentes sem fazer suposições ou usar um relé (que então não é mais "perfuração")?
Responder1
O termo NATs não bem comportados está incorreto - qualquer dispositivo NAT que use PAT (tradução de endereço de porta) para agregar vários endereços privados em um único endereço público irá remapear as portas de origem. É a isso que "Endereço da Porta" se refere no PAT.
Seria impossível para dois dispositivos internos usarem o mesmo endereço de origem para o mesmo destino e esperar que a porta de origem permanecesse a mesma após o NAT, e não beneficia a postura de segurança tentar manter a porta de origem consistente ao direcionar Múltiplos destinos. Portanto, esse geralmente não é um objetivo que os firewalls tenham em seu design.
É claro que isso não ajuda aqui, onde você deseja saber a porta de origem de uma conexão, sem realmente receber nenhum pacote dessa origem. Uma retransmissão é a opção óbvia em que os terminais se comunicam através de terceiros (sim, uma retransmissão apenas transfere pacotes entre soquetes, como você sugere - a implementação é provavelmente muito mais complexa nos servidores Skype, mas em princípio é a mesma).
É difícil ver como você poderia fazer isso de outra maneira, já que os endpoints não estão cientes das traduções que acontecem durante o vôo, então eles não poderiam nem comunicar qual é sua porta de origem através de algum tipo de canal lateral (como apenas registrando a porta com um servidor central, mas comunicando-se diretamente).