Perfuração simétrica de NAT e UDP

Eu li essa pergunta , mas a explicação do NAT simétrico não foi detalhada o suficiente.

Alguém poderia me ajudar a entender os parágrafos a seguir?

Eu li isso sobre o NAT simétrico :

Cada solicitação do mesmo endereço IP interno e porta para um endereço IP e porta de destino específico é mapeada para um endereço IP e porta IP de origem externos exclusivos, se o mesmo host interno enviar um pacote mesmo com o mesmo endereço e porta de origem, mas para um endereço diferente. destino, um mapeamento diferente é usado. Somente um host externo que recebe um pacote de um host interno pode enviar um pacote de volta.

http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT

E isso sobre furação UDP :

A perfuração UDP não funcionará com dispositivos NAT simétricos (também conhecidos como NAT bidirecional), que tendem a ser encontrados em grandes redes corporativas. No NAT simétrico, o mapeamento do NAT associado à conexão com o servidor STUN conhecido é restrito ao recebimento de dados do servidor conhecido e, portanto, o mapeamento NAT que o servidor conhecido vê não é uma informação útil para o terminal.

http://en.wikipedia.org/wiki/UDP_hole_punching

Mas eu realmente não estou absorvendo isso. Tenho a sensação de que está me dizendo que (em um aplicativo cliente-servidor em que o cliente inicia a comunicação) um servidor não pode se comunicar de outra maneira, a menos que isso seja explicitamente permitido pelo dispositivo NAT. Não entendo por que é isso que está dizendo. Se for possível, você poderia simplificar essa descrição um pouco para mim?

Temos um problema em nosso ambiente em que uma ferramenta de suporte remoto conhecida não pode ser usada por um fornecedor de software igualmente conhecido para fornecer suporte. O cliente tem reconhecimento de proxy, mas, para alguns usuários, pode ser uma boa ideia não usá-lo e fazer algo completamente diferente via UDP na porta 1153.

Do nosso bate-papo ... para que outros possam não ter a conversa completa, mas o básico está aqui.

NAT tão básico = source address:port >> external address:port >> NAT>> new source address:port >> external address port

com NAT simétrico, é um mapeamento estático e sempre o mesmo, tanto para a origem quanto para o destino.

Exemplo: 192.168.100.5:34983 going to 4.2.2.2:53 then REQUIRE it to be 216.222.222.222:44444 with destination 8.8.8.8:333333

"em um aplicativo cliente-servidor em que o cliente inicia a comunicação) um servidor não pode se comunicar de outra maneira, a menos que isso seja explicitamente permitido pelo dispositivo NAT."

Na parte que você diz estar incorreta , deve ler-se:

em um aplicativo cliente-servidor em que o cliente inicia a comunicação) um servidor PODE se comunicar de outra maneira DEPOIS que a fonte estabeleça a sessão SOBRE AS portas usadas na sessão.

Ou seja, se 2.2.2.2:43424 for para 5.5.5.5:80 e 5.5.5.5:80 enviará as informações de volta para 2.2.2.2:43424 assim que a sessão for estabelecida. Na sua frase ... a sessão seria apenas uma fonte que se comunicaria com o destino com o destino, nunca respondendo com pacotes / informações / gráficos / o que for.

"Temos um problema em nosso ambiente, em que uma ferramenta de suporte remoto conhecida não pode ser usada por um fornecedor de software igualmente conhecido para fornecer suporte. O cliente tem reconhecimento de proxy, mas, por algum motivo, acha que pode ser um boa ideia não usá-lo e fazer algo completamente diferente via UDP na porta 1153. "

Isso pode ser porque eles simplesmente bloqueiam o Logmein / Teamviewer / o que quer que seja no nível da porta, pois pedem para usar uma porta diferente ... então eles pensam que se você permitir ou se comunicar no 1153, contornará suas próprias restrições de TI ... melhor Posso pensar sem saber em detalhes qual aplicativo ou detalhes completos. Nada a ver com a perfuração simétrica de NAT ou UDP realmente ... pelo menos no que diz respeito ao problema que eles estão trazendo.

Eu recomendaria conversar com a equipe de suporte sobre com qual ferramenta de suporte remoto eles trabalham OU com eles para determinar uma maneira de usar a ferramenta que você gosta. Se isso significa certas regras / NAT de porta, você precisará trabalhar com eles e sua equipe de Rede para descobrir essa parte.

Espero que tudo ajude.

Veja estas fotos tiradas da página "Tradução de endereços de rede" da Wikipedia.

Em "Cone completo NAT"

1. Depois que um endereço interno (iAddr: iPort) é mapeado para um endereço externo (eAddr: ePort), todos os pacotes do iAddr: iPort são enviados por meio do eAddr: ePort.
2. Qualquer host externo pode enviar pacotes para o iAddr: iPort enviando pacotes para o eAddr: ePort.

Em NAT simétrico

1. Cada solicitação do mesmo endereço IP interno e porta para um endereço IP e porta de destino específicos é mapeada para um endereço IP e porta de origem externa exclusivos; se o mesmo host interno enviar um pacote mesmo com o mesmo endereço e porta de origem, mas para um destino diferente, um mapeamento diferente será usado.
2. Somente um host externo que recebe um pacote de um host interno pode enviar um pacote de volta.

Agora vamos discutir por que o furador UDP não pode funcionar no NAT simétrico. Digamos que o Servidor1 seja o servidor STUN e o Servidor 2 seja o dispositivo NAT de rede privada diferente. Na perfuração UDP, o Cliente se conecta ao Servidor1 e o mapeamento de portas é criado no dispositivo NAT. Mas quando esse cliente se conecta ao host atrás do Server2, o dispositivo NAT cria outro mapeamento de porta, como mostrado na figura 2. O Server1 compartilha o mapeamento da porta do cliente com o host atrás do Server2 e com esse mapeamento de porta o Server2 não pode fazer uma conexão e o Server2 não está ciente do segundo mapeamento de porta criado pelo dispositivo NAT.