c++ - socket - Perforación UDP

winsock2 0

Question

Tengo algunas preguntas sobre la perforación con UDP. Basado en el wiki http://en.wikipedia.org/wiki/UDP_hole_punching

1) Para configurar una sesión UDP entre dos partes (el cliente que está detrás de NAT, servidor que no es NAT), el cliente simplemente tiene que enviar un paquete al servidor y luego la sesión está permitida en ambos sentidos (enviar y recibir ) a través del firewall? Lo que significa que el cliente también puede recibir del servidor.

2) Perforación del orificio UDP: dos clientes se conectan primero al servidor, luego el servidor proporciona un puerto / ip del cliente a otros clientes, por lo que los clientes se envían paquetes entre ellos en esos puertos. ¿Es esto correcto?

3) si el # 2 es verdadero, ¿por qué los cortafuegos permitirán que se reciban datos de otra dirección IP distinta a la utilizada para establecer la conexión en ese mismo puerto? ¿Suena como un gran agujero de seguridad que debería ser filtrado fácilmente? Entiendo que la suplantación de IP de origen podría engañar, ¿pero esto?

Gracias de antemano, Johan

Answer 1

1) Sí, con la mayoría de los cortafuegos razonables, a menos que lo configure en modo extremadamente paranoico.

2) No exactamente. Este artículo lo explica con más detalle, pero la idea es que uno de los clientes primero envíe un datagrama a la IP pública del otro. Entonces este datagrama se descarta, pero el otro cliente sabe que fue enviado porque el primero lo contó a través del servidor. Luego, el otro cliente envía un datagrama de regreso al primero al mismo puerto desde el cual se originó el primer datagrama. Como NAT en el primer cliente recuerda que había un paquete desde ese puerto, considera que el datagrama entrante es una respuesta al primero. El problema aquí es averiguar qué puerto público NAT elegirá enviar el primer datagrama, pero la mayoría de los NAT lo hace de manera predecible, por lo que casi siempre funciona bien, a veces no desde el primer intento.

Answer 2

1) Sí. Sin embargo, no necesita perforar si está contactando un servidor que no es NAT. Su aplicación cliente simplemente se comporta normalmente.

2) Sí.

3) Algunos NATs ciertamente restringen un puerto público a solo un par de emisor-receptor. Si necesita perforar en tal escenario, su única posibilidad es adivinar el puerto público que NAT elegirá para la conexión directa.

Sin embargo, NAT no es una característica de seguridad. Por lo tanto, aceptar cualquier paquete en el puerto público no es un problema de seguridad, ya que no hay diferencia con el caso simple de un cliente conectado directamente a Internet.