Nat Traversal, colegas incapazes de se comunicar

Question

Atualmente, estou trabalhando em um projeto que requer NAT transversal, mas parece que estou com dificuldades. Eu tenho a seguinte configuração em execução para testes:

• R1, roteador Verizon Fios conectado à internet.
• R2, roteador Belkin conectado em sua porta WAN ao switch de R1 via ethernet.
• i, O servidor introdutório, conectado via ethernet a R1. R1 encaminha a porta 6666 para i.
• A e B, computadores executando o software cliente conectado ao R2 via Wifi.

Introdução ao servidor e cliente:

Quando A e B iniciam seu cliente, o cliente envia um "HelloPacket" para o endereço externo de R1 (72.82.59.10) na porta 6666.

Ao receber um HelloPacket, o servidor primeiro verifica se ele já viu o endereço de origem e o identificador da porta de origem.

• Se não, ele primeiro envia cada entrada em sua tabela de identificadores de peer (ip / port de origem) para o par de onde recebeu o HelloPacket, e então armazena isso como uma nova entrada em sua tabela peer.
• Se tiver, ele redefine o tempo limite dos peers para que saiba continuar enviando esse identificador de peers para os pares que se conectam no futuro.

Após o cliente enviar inicialmente o HelloPacket para o servidor Intro, ele pode esperar receber pacotes chamados IntroPackets do servidor, se houver pares que já tenham se apresentado ao servidor. Estes IntroPackets contêm o ip / port externo e interno de um par.

Agora que o peer conhece os pares existentes, é responsabilidade do recém-conectado enviar um HelloPacket aos pares existentes para informá-los de sua existência. É aqui que estou tendo problemas.

Eu não tenho reputação suficiente para postar imagens, mas aqui está um diagrama que fiz na pintura da configuração: link

Aqui está a ordem dos eventos e o problema que estou enfrentando:

1. O servidor de introdução é iniciado e está atento a pacotes UDP do tipo "HelloPacket"
2. O peer A inicia seu cliente que, por sua vez, envia um HelloPacket para o servidor Intro no endereço / porta: 72.82.59.10, 6666
3. O servidor de intro recebe o HelloPacket e adiciona uma entrada à sua tabela e não envia nenhum IntroPackets para o peer A, pois não há outros pares em sua tabela. A entrada na tabela é semelhante à seguinte para o ponto A: IP: 72.82.59.10, porta: 1024
4. O peer B inicia seu cliente, que, por sua vez, envia um HelloPacket para o servidor de introdução.
5. O servidor de introdução recebe o HelloPacket e adiciona uma entrada à sua tabela. O servidor de intro então envia um IntroPacket para o peer recém-conectado que contém o endereço e a porta do par A. A tabela do servidor de introdução é semelhante à seguinte neste ponto:

Ponto A: 72,82.59,10, 1024

Ponto B: 72,82.59,10, 1025

6. O peer B recebe o IntroPacket e tenta enviar um pacote de saudação para o peer A
.

O passo 6 é onde meu design está falhando. O Peer A nunca recebe o HelloPacket do ponto B. É do meu conhecimento que quando o roteador recebe um pacote com uma porta de destino de 1024, ele o mapeará para o endereço interno e para a porta usando seu NAT. Está correto?

Eu tentei executar um programa externo que apenas envia datagramas para o endereço externo e a porta mapeada para o cliente A, mas estes não parecem estar passando, então não acho que seja um problema de tempo limite.

Eu também sei que devo tentar conectar-me ao endereço interno e à porta para ver se os clientes estão por trás do mesmo NAT e planejam implementá-lo no futuro.

Além disso, toda a comunicação é feita de forma confiável usando o Go-Back-N no código do cliente e do servidor.

Perguntas:

1. Eu estou negligenciando algo crucial no meu design ou simplesmente não entendendo o NAT traversal com o UDP?
2. Por que motivos o Peer A seria capaz de receber um pacote do servidor, mas não do Peer B? (Como pares são capazes de receber pacotes de volta do servidor)
3. O NAT leva o endereço de origem em consideração?

Qualquer entrada é muito apreciada !! Obrigado!