Corríjame si me equivoco, pero para que un nodo participe peer-to-peer, si está detrás de un NAT, lo más avanzado es poder conectarse. ¿Por qué es necesario el reenvío de puertos? Sé que hay excepciones a esto, es decir, los recorridos de NAT, pero me gustaría entender el problema básico primero. ¿Alguien puede explicar en términos muy simples?
Básicamente, mi pregunta es cuándo y por qué es el reenvío de puertos nescecary?
Hay 2 tipos principales de NAT, puede tener uno a uno NAT (NAT estática) donde se traduce una dirección IP interna a una IP externa, y tiene varios a uno NAT (ocultar NAT) donde se asignan muchas direcciones IP a una sola dirección IP. En muchos a uno NAT cuando un host interno se conecta a un host externo, la información de IP se coloca en las tablas de sesión (estoy usando esto como un término genérico para abarcar todas las tablas que un firewall puede usar en este caso) para que el firewall sepa Qué hacer con los paquetes de devolución.
Las cosas se complican un poco más para las sesiones iniciadas por un host fuera del firewall. Con NAT uno a uno es muy simple ya que solo hay un lugar donde puede ir el paquete, pero cuando hay muchos hosts detrás de una sola dirección IP, el dispositivo de enrutamiento no tiene un indicador de hacia dónde debe dirigirse un paquete entrante. El reenvío de puertos es una forma de resolver este problema; una regla de reenvío de puertos permitirá que el dispositivo realice la traducción de la dirección de destino y reenvíe el paquete en consecuencia.
La traducción de puertos no se usa a menudo como una solución en redes empresariales, aunque puedo pensar en algunas excepciones. Las empresas generalmente tienen un bloque de IP enrutables públicamente, por lo que configurarán un NAT uno a uno cuando un host interno requiera acceso desde una IP externa (o simplemente asigne una IP externa a la caja en primer lugar). La traducción de puertos es mucho más que una solución de banda ancha doméstica donde su enrutador solo tiene una dirección IP para usar. Cuando encienda su software p2p, las conexiones iniciadas externamente no podrán alcanzarlo a menos que haya una configuración de reenvío de puertos, ya sea manualmente, pero con mayor probabilidad UPnP, donde la aplicación le dice al enrutador cuál debe ser la configuración de reenvío de puertos.
Supongamos que tiene un software, que está escuchando en un puerto específico. El problema básico es que no sabe cuál será este número de puerto después de NAT transversal. Es importante porque el software remoto tiene que saber esto para poder crear una conexión.
(Más detalles: debe conocer este puerto después de NAT transversal y enviarlo al cliente remoto. ¿Qué pasa si ese cliente también está detrás de un NAT?)
El ejemplo común de un protocolo P2P es Bittorrent. En este protocolo, las comunicaciones a menudo son gestionadas por un rastreador. Esto significa que para la transferencia de datos, se necesitan un mínimo de tres nodos:
+-----+ +---------+ +------+
| | 1.1.1.1:500 | | | |
| You |<------------->| Tracker |<---->| Peer |
| | | | | |
+-----+ +---------+ +------+
La conexión para usted comienza con decirle al rastreador su dirección IP y el puerto en el que se puede conectar. El rastreador luego almacena esto en una tabla de estado:
+--------------+------------+
| Nodes | Completion |
| 1.1.1.1:500 | 0% |
| 2.2.2.2:1000 | 100% |
+--------------+------------|
Peer ha establecido que se puede conectar en el puerto 1000. Volveremos a esto.
Las direcciones 1.1.1.1 y 2.2.2.2 representan las direcciones externas de los dispositivos NAT. Estos dispositivos son omnipresentes en la Internet de hoy en día, ya que casi todos los usuarios tienen un enrutador instalado para proporcionar acceso a varias computadoras, teléfonos móviles, consolas de juegos, etc.
Esto significa que detrás de estas direcciones hay más direcciones, una para cada uno de estos dispositivos.
Sin embargo, dado que una dirección solo puede conectarse a un puerto en el rango 1-65535 , ¿cómo sabe su enrutador si conectar una solicitud del puerto 500 a su computadora con su cliente torrent en ejecución? Usted lo instruye, proporcionándole una regla llamada puerto hacia adelante para que diga "cualquier conexión que reciba en el puerto 500, quiero que se me envíe", donde me es su dirección interna (una de 10.x.x.x , 192.168.x.x o 172.16.x.x ).
Cuando acaba de unirse al 'enjambre' al anunciar al rastreador, el rastreador le envía la tabla de estado anterior. Sabes que acabas de unirte y tienes un 0% de finalización, pero ese Peer tiene un 100% de finalización, lo que significa que sabes que si te conectas con él podrás comenzar a obtener los datos.
Si Peer no ha "reenviado" su puerto (1000, según informó al rastreador cuando anunció), sin embargo, no podrá conectarse y comenzar a recibir datos. Obviamente, esto no es deseable ya que ahora no puede completar el torrent porque no hay nadie disponible para compartirlo.
Si Peer no ha anunciado desde que te conectaste, aún no sabe que existes. Sin embargo, si ha configurado el reenvío de puertos correctamente, cuando él anuncie y obtenga la nueva tabla de estado con usted, podría iniciar la conexión con usted. Esto funcionará ya que su puerto se reenvía.
Si ambos de ustedes no tenían habilitado el reenvío de puertos, entonces a pesar del hecho de que ambos estaban anunciando al rastreador, porque los puertos de los que le dijo al rastreador no llegan realmente a su máquina , todas las conexiones de datos posibles están bloqueadas por sus enrutadores / dispositivos NAT.
En resumen: el reenvío de puertos ayuda con la salud del intercambio de datos P2P al facilitar el establecimiento de las conexiones, y a menos que cada miembro permita algún tipo de reenvío de puertos, es imposible intercambiar datos de una manera P2P.