Normalmente, una NAT mantendrá el mismo punto final público de un punto final local para todos los paquetes que provienen de él, lo que hace que la perforación UDP sea fácilmente posible. Sin embargo, algunos NAT asignarán el punto final local a uno público diferente para cada host diferente al que se envía un paquete, lo que hace que no sea posible perforar UDP.
La única forma de realizar la perforación UDP tradicional sería adivinar el punto final remoto. Sin embargo, dado que hay más de 65.000 puertos, este método no es muy fiable. He leído que aplicaciones como Skype, que, a sabiendas, pueden comunicarse a través de prácticamente cualquier tipo de NAT, utilizan un relé para eso. Aquí están mis preguntas:
Un relé es simplemente un socket que transfiere datos entrantes de un socket a otro, ¿verdad? ¿Existen otras formas de perforar UDP a través de NAT traviesos sin hacer conjeturas descabelladas o usar un relé (que entonces ya no es realmente "perforar agujeros")?
Respuesta1
El término NAT que no se comporta bien es incorrecto: cualquier dispositivo NAT que utilice PAT (traducción de direcciones de puertos) para agregar varias direcciones privadas a una única dirección pública reasignará los puertos de origen. Esto es a lo que se refiere "Dirección de puerto" en PAT.
Sería imposible que dos dispositivos internos usen la misma dirección de origen para el mismo destino y esperar que el puerto de origen siga siendo el mismo después de realizar NAT, y no beneficia la postura de seguridad intentar mantener el puerto de origen consistente al apuntar Destinos Múltiples. Por lo tanto, este no es generalmente un objetivo que los cortafuegos tengan en su diseño.
Por supuesto, esto no ayuda aquí, donde desea saber el puerto de origen de una conexión, sin recibir ningún paquete de esa fuente. Una retransmisión es la opción obvia donde los puntos finales se comunican a través de un tercero (sí, una retransmisión simplemente transfiere paquetes entre sockets como usted sugiere; la implementación es probablemente mucho más compleja dentro de los servidores de Skype, pero en principio es lo mismo).
Es difícil ver cómo se podría hacer esto de otra manera, ya que los puntos finales no son conscientes de las traducciones que ocurren durante el vuelo, por lo que ni siquiera podrían comunicar cuál es su puerto de origen a través de un canal lateral de algún tipo (como sólo registrando el puerto con un servidor central pero comunicándose directamente).