¿Qué es la perforación de agujeros TCP?

http://en.wikipedia.org/wiki/TCP…

Es muy probable que su dispositivo informático esté conectado a Internet a través de algún tipo de enrutador que también actúa como NAT. Los NAT simplemente toman una conexión a Internet y permiten que muchos otros dispositivos usen esa conexión única (IP). Esto crea un problema en el que si una parte externa desea conectarse a SU dispositivo (que está detrás de un NAT), el NAT generalmente no podrá comprender la naturaleza de la solicitud entrante porque no hay forma de abordar un dispositivo específico detrás del enrutador / NAT. Esto a su vez conduce a un patrón de diseño de conexiones realizadas desde su dispositivo al mundo exterior porque no hay problema con eso.

Entonces, ¿qué es la perforación de agujeros TCP? Es un conjunto de técnicas en las que un dispositivo externo e interno, generalmente en coordinación con un tercero, realizan una serie de intentos de conexión entre sí que tienen la intención de fallar, pero como efecto secundario dejan un puerto entrante abierto. Este puerto entrante más tarde permite que la parte externa se conecte a través de la NAT a la parte interna. Es extraño, apenas es ciencia, pero se puede hacer con muchos enrutadores.

¿Por qué se hace esto? Por lo general, al implementar conexiones P2P, debe conectar dos dispositivos en Internet. Más a menudo de lo que cabría esperar, al menos uno, si no ambos dispositivos, están detrás de un NAT. Esto a su vez significa que si sigue las reglas, entonces estos dispositivos no podrán conectarse directamente, y tendrá que hacer un túnel de los datos que fluyen entre ellos a través de un servidor de terceros que le cuesta $$$. Entonces, a la gente se le ocurrieron varios trucos para aumentar el% de conexiones que son directas y no tunelizadas.

Para agregar a la respuesta de Ohad, el siguiente documento proporciona un buen resumen de las técnicas conocidas de perforación de agujeros TCP:

http: //nutss.gforge.cis.cornell

Los métodos etiquetados como STUNT # 2 y P2PNAT son los más simples y más propensos a funcionar.

La esencia de la idea es utilizar un servidor intermediario para facilitar el intercambio de direcciones IP públicas y puertos predichos para ambos extremos de la conexión deseada. Luego, cada lado inicia una conexión con el par de dirección IP pública del puerto mientras escucha simultáneamente los SYN entrantes. Esto da como resultado que se envíen dos SYN. En cada extremo, un NAT creará una asignación bidireccional entre el puerto de dirección del host interno y una combinación de puerto de dirección en el lado externo del NAT. Si el puerto se predijo correctamente (y se pasó a la parte remota a través del intermediario), el NAT finalmente reenviará el SYN remoto al host interno. Esto da como resultado la transición de estado TCP “abierto simultáneo” o una transición “sincronizada recibida” del estado ESCUCHAR. STUNT # 2 y P2PNAT varían la secuencia y la vida de estas operaciones, pero por lo demás son bastante similares.

Consulte el siguiente diagrama de estado TCP para ver las transiciones mencionadas anteriormente:

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

Tenga en cuenta que la predicción de puertos es necesaria para manejar las discrepancias en la forma en que los NAT asignan los puertos internos a los puertos externos; ver http://en.wikipedia.org/wiki/Net… . El recorrido UDP NAT, que se usa más comúnmente (por ejemplo, Skype), usa ideas similares pero es más simple, ya que no tiene conexión y carece de la complejidad de una máquina de estados. Por lo tanto, la predicción de puertos es innecesaria ya que es probable que las asignaciones de puertos UDP internos / externos sean estáticas por un período de tiempo e independientes de la dirección remota (sin conexión). Los dos clientes pueden proceder directamente al envío de datagramas entre ellos después de intercambiar datos del puerto de direcciones públicas a través del intermediario, y el recorrido NAT funcionará mágicamente en la mayoría de los casos.