NAT Simétrica e Perfuração UDP

Question

Li esta questão , mas a explicação de NAT simétrico não foi detalhado o suficiente.

Por favor, alguém poderia me ajudar a entender os parágrafos seguintes?

Eu li sobre o NAT Simétrico :

Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port, if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used. Only an external host that receives a packet from an internal host can send a packet back.

link

E isso é sobre Perfuração do UDP :

UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the well known STUN server is restricted to receiving data from the well-known server, and therefore the NAT mapping the well-known server sees is not useful information to the endpoint.

link

Mas eu não estou realmente 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 poderia se comunicar de outra maneira, a menos que fosse explicitamente permitido pelo dispositivo NAT. Eu não entendo porque é isso que está dizendo. Se for possível, você poderia simplificar esta descrição para mim?

Temos um problema em nosso ambiente em que uma ferramenta de suporte remoto bem conhecida não pode ser usada por um fornecedor de software igualmente conhecido para fornecer suporte a nós. O cliente é ciente do proxy, mas para alguns reson ele acha que pode ser uma boa idéia não usá-lo e fazer algo completamente diferente via UDP na porta 1153.

    

Answer 1

Em nosso bate-papo ... para que outros não consigam 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 o mesmo o tempo todo e para origem e 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

"in a client-server application where the client initiates the communication) a server could not communicate back the other way unless it were explicitly permitted by the NAT device."

essa parte que você diz está incorreta deveria ler:

in a client-server application where the client initiates the communication) a server CAN communicate back the other way AFTER the source establishes the session OVER the ports used in the session.

Significando se 2.2.2.2:43424 vai para 5.5.5.5:80, então 5.5.5.5:80 envia as informações de volta para 2.2.2.2:43424 assim que a sessão é estabelecida. Em sua sentença ... a sessão só seria fonte se comunicando ao destino com destino nunca respondendo com pacotes / info / graphics / whatever.

"We have an issue in our environment where a well-known remote support tool cannot be used by an equally well-known software vendor to provide support to us. The client is proxy-aware, but for some reson it thinks it might be a good idea not to use it and do something completely different via UDP on port 1153."

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

Eu recomendaria falar com a equipe de suporte sobre em qual ferramenta de suporte remoto eles trabalham ou em trabalhar com eles para determinar uma maneira de usar a ferramenta de que você gosta. Se isso significa que certas regras / NATs de porta, você precisará trabalhar com elas e sua equipe de Networking para descobrir essa parte.

Espero que tudo ajude.

    

Answer 2

Veja essas fotos tiradas da página "Tradução de endereços de rede" da Wikipédia.

Em "Full Cone NAT"

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

No 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. Apenas um host externo que recebe um pacote de um host interno pode enviar um pacote de volta.

Agora vamos discutir por que a perfuração UDP não funciona no NAT Simétrico. Vamos dizer que o Servidor1 é o Servidor STUN e o Servidor 2 é um dispositivo NAT de uma Rede Privada diferente. Em perfuração UDP, o cliente se conecta ao Server1 e o mapeamento de porta é criado no dispositivo NAT. Mas quando esse cliente se conecta ao host atrás de Server2, o dispositivo NAT cria outro mapeamento de portas, como mostrado na figura 2. O Server1 compartilha o mapeamento de porta do cliente com o host atrás de Server2 e com esse mapeamento de porta Server2 não pode estabelecer uma conexão e Server2 não está ciente do segundo mapeamento de porta criado pelo dispositivo NAT.