Fallo en realizar perforación de agujero TCP utilizando STUN.
Tengo dos hosts, A y B. Están en redes diferentes, detrás de NAT y operadores de Internet distintos. Estoy intentando establecer una conexión punto a punto entre ellos utilizando una técnica llamada «hole punching». Estoy utilizando un servidor STUN para obtener las direcciones IP y puertos mapeados tanto para A como para B. El proceso es el siguiente:
Para A:
.\stunclient.exe --mode behavior stunserver.stunprotocol.org 3478
Prueba de enlace: éxito
Dirección local: 192.168.0.110:54709
Dirección mapeada: 186.233.160.141:28769
Prueba de comportamiento: éxito
Comportamiento NAT: Mapeo independiente de extremo
Para B:
.\stunclient.exe --mode behavior stunserver.stunprotocol.org 3478
Prueba de enlace: éxito
Dirección local: 192.168.3.1:57015
Dirección mapeada: 45.70.35.52:12870
Prueba de comportamiento: éxito
Comportamiento NAT: Mapeo independiente de extremo
Luego, intento realizar la técnica de hole punching utilizando TCP (usando netcat) ejecutando estas dos líneas simultáneamente y varias veces en A y B:
En A:
ncat -p 54709 45.70.35.52 12870
Ncat: TIMEOUT.
En B:
ncat -p 57015 186.233.160.141 28769
Ncat: TIMEOUT.
Siempre obtengo «Ncat: Timeout» como resultado (no de inmediato, sino después de un tiempo). Sin embargo, pude realizar una conexión directa entre A y B utilizando hole punching mediante UDP ejecutando los siguientes comandos tres veces:
En A:
ncat -u -p 54709 45.70.35.52 12870
En B:
ncat -u -p 57015 186.233.160.141 28769
Entonces, el problema es que el hole punching TCP no está funcionando. ¿Alguna idea de por qué?
davy.ai
Una posible razón por la que TCP hole punching no funciona podría ser debido al hecho de que algunos dispositivos NAT solo permiten el tráfico entrante a puntos finales que ya han iniciado una conexión desde dentro de la red. Esto se conoce como “mapeo dependiente de dirección y puerto”, lo que significa que un punto final externo solo puede enviar tráfico a un punto final interno si el punto final interno ya ha enviado tráfico al punto final externo utilizando la misma combinación de dirección y puerto. Dado que TCP requiere una fase de establecimiento de conexión y los puntos finales externos no están iniciando la conexión, algunos NAT pueden descartar el tráfico entrante, lo que causa el error de tiempo de espera.
Otra razón podría deberse a la configuración del firewall en cualquiera de los hosts que podrían estar bloqueando el tráfico entrante. También es posible que el comportamiento NAT de A y B no sea exactamente como se informa por el servidor STUN, y pueden ser necesarias algunas configuraciones o técnicas adicionales para establecer la conexión TCP.