Perforación simétrica de agujeros NAT y UDP

He leído esta pregunta , pero la explicación de Symmetric NAT no fue lo suficientemente detallada.

¿Podría alguien ayudarme a entender los siguientes párrafos?

Leí esto sobre NAT simétrica :

Cada solicitud de la misma dirección IP y puerto internos a una dirección IP y puerto de destino específicos se asigna a una dirección IP y puerto de origen externo único, si el mismo host interno envía un paquete incluso con la misma dirección y puerto de origen pero a un puerto diferente destino, se utiliza un mapeo diferente. Solo un host externo que recibe un paquete de un host interno puede devolver un paquete.

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

Y esto sobre la perforación de agujeros UDP :

La perforación de agujeros UDP no funcionará con dispositivos NAT simétricos (también conocidos como NAT bidireccionales) que tienden a encontrarse en grandes redes corporativas. En NAT simétrica, la asignación de NAT asociada con la conexión al conocido servidor STUN está restringida a recibir datos del servidor conocido y, por lo tanto, la asignación de NAT que ve el servidor conocido no es información útil para el punto final.

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

Pero realmente no lo estoy absorbiendo. Tengo la sensación de que me está diciendo que (en una aplicación cliente-servidor donde el cliente inicia la comunicación) un servidor no puede comunicarse de otra manera a menos que el dispositivo NAT lo permita explícitamente. No entiendo por qué eso es lo que dice. Si es posible, ¿podría simplificarme un poco esta descripción?

Tenemos un problema en nuestro entorno en el que un proveedor de software igualmente conocido no puede utilizar una herramienta de soporte remoto bien conocida para brindarnos soporte. El cliente es compatible con proxy, pero, por alguna razón, cree que podría ser una buena idea no usarlo y hacer algo completamente diferente a través de UDP en el puerto 1153.

Desde nuestro chat ... por lo que otros pueden no tener la conversación completa, pero los conceptos básicos están aquí.

Así que NAT básico = source address:port >> external address:port >> NAT>> new source address:port >> external address port

con NAT simétrico es un mapeo estático y lo mismo cada vez y para el origen Y el destino.

Ejemplo: 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

"en una aplicación cliente-servidor donde el cliente inicia la comunicación) un servidor no podría comunicarse de otra manera a menos que el dispositivo NAT lo permitiera explícitamente".

esa parte que dices es incorrecta , debería leer:

en una aplicación cliente-servidor donde el cliente inicia la comunicación) un servidor PUEDE comunicarse de otra manera DESPUÉS de que la fuente establezca la sesión SOBRE los puertos utilizados en la sesión.

Es decir, si 2.2.2.2:43424 pasa a 5.5.5.5:80, 5.5.5.5:80 envía la información nuevamente a 2.2.2.2:43424 una vez que se establece la sesión. En su oración ... la sesión solo sería fuente comunicándose con destino con destino, nunca respondiendo con paquetes / información / gráficos / lo que sea.

"Tenemos un problema en nuestro entorno donde una herramienta de soporte remoto bien conocida no puede ser utilizada por un proveedor de software igualmente conocido para brindarnos soporte. El cliente es compatible con proxy, pero por alguna resonancia cree que podría ser un buena idea no usarlo y hacer algo completamente diferente a través de UDP en el puerto 1153 ".

Eso podría deberse a que simplemente bloquean Logmein / Teamviewer / lo que sea a nivel de puerto ya que solicitan usar un puerto diferente ... por lo que piensan que si permite o se comunica en 1153, eludirá sus propias restricciones de TI ... mejor Puedo pensar sin saber en detalle qué aplicación o detalles completos. Nada que ver con la perforación simétrica de agujeros NAT o UDP realmente ... al menos en lo que respecta al problema que están planteando.

Recomendaría hablar con su equipo de soporte sobre la herramienta de soporte remoto con la que trabajan O trabajar con ellos para determinar la forma de usar la herramienta que te gusta. Si esto significa ciertas reglas / NAT de puertos, deberá trabajar con ellos y su equipo de redes para resolver esa parte.

Espero que todo ayude.

Mire estas imágenes tomadas de la página de Wikipedia "Traducción de direcciones de red".

En "Full Cone NAT"

1. Una vez que una dirección interna (iAddr: iPort) se asigna a una dirección externa (eAddr: ePort), cualquier paquete de iAddr: iPort se envía a través de eAddr: ePort.
2. Cualquier host externo puede enviar paquetes a iAddr: iPort enviando paquetes a eAddr: ePort.

En NAT simétrica

1. Cada solicitud desde la misma dirección IP interna y puerto a una dirección IP y puerto de destino específicos se asigna a una dirección IP y puerto de fuente externa única; Si el mismo host interno envía un paquete incluso con la misma dirección de origen y puerto pero a un destino diferente, se utiliza una asignación diferente.
2. Solo un host externo que recibe un paquete de un host interno puede devolver un paquete.

Ahora analicemos por qué la perforación de agujeros UDP no puede funcionar en NAT simétrica. Digamos que Server1 es STUN Server y Server 2 es un dispositivo NAT de diferentes redes privadas. En la perforación de agujeros UDP, el Cliente se conecta con el Servidor1 y la asignación de puertos se crea en el dispositivo NAT. Pero cuando este cliente se conecta al host detrás del Servidor2, el dispositivo NAT crea otro mapeo de puertos como se muestra en la imagen 2. El Servidor1 comparte el mapeo de puertos del cliente con el host detrás del Servidor2 y con este mapeo de puertos el Servidor2 no puede establecer una conexión y el Servidor2 no conoce el segundo mapeo de puertos creado por el dispositivo NAT.