Chownat es un fantástico script perl que permite que dos ordenadores que se encuentre en redes locales diferentes y accedan a internet a través de un servidor que hace NAT con firewall puedan conectarse directamente sin tener que redirigir puertos. Es decir, si tenemos una configuración:
Ordenador A -> Servidor LAN NAT1 -> Internet <- Servidor LAN NAT2 <- Ordenador B
De forma directa, el ordenador A no podria establecer una conexión a un puerto del ordenador B ya que el Servidor NAT2 no permitiria ese tráfico, básicamente pq si la red local está compuesta por varios ordenadores no sabria a quien dirigir dicho paquete a no ser que tenga definida una regla explicita. La solución habitual es precisamente definir estas reglas, pero no siempre tenemos el control del servidor de salida de nuestra red.
Chownat aprovecha las características de NAT para hacer posible una conexión directa desde el ordenador A a un puerto del ordenador B sin tener que cambiar la configuración de los servidores.
Supongamos que el Ordenador B tiene un servidor web en el puerto 80 y queremos acceder desde el ordenador A. En el ordenador B vamos a ejecutar:
./chownat.pl -d -s 80 ip_publica_servidor_nat1
Esto hará que nuestro ordenador empiece a enviar paquetes UDP al servidor NAT1 al puerto 2222, por supuesto el servidor lo que hará será descartar automáticamente dicho tráfico ya que no sabrá a quien va dirigido. Sin embargo, el servidor NAT2 observará que se está enviando desde el ordenador B trafico a la ip del servidor NAT1 (puerto 2222) y por tanto se “anotará” que si recibe algo procedente de ahí lo redirija a nuestro ordenador B (así es como funciona el NAT habitualmente, un servidor NAT ve como establecemos una conexión a una determinada IP/puerto y nos redirigirá la respuesta automáticamente).
Seguidamente en el ordenador A ejecutaremos:
./chownat.pl -d -c 8000 ip_publica_servidor_nat2
Esto hará 2 cosas:
1) Empezará a enviar paquetes UDP al servidor nat2 puerto 2222, este servidor aceptará estos paquetes y creerá que se trata de respuestas a la información enviada previamente por el ordenador B, por tanto redireccionará automáticamente el tráfico a dicho ordenador. A la misma vez, el servidor nat1 observá que estamos enviando tráfico al servidor nat2 por el puerto 2222 y automáticamente nos redireccionará todo aquello que llegue de allí. Os recuerdo que los scripts envian de forma constante estos paquetes, por tanto en este punto ya seremos capaces de llegar de extremo a extremo.
2) Se abre el puerto 8000 en la máquina local (ordenador A) y se establece un tunel entre dicho puerto y el puerto 80 remoto de forma que realmente nuestro tráfico viajará por la conexión UDP que hemos establecido anteriormente al puerto 2222.
Ahora ya podemos acceder al servidor web del ordenador B abriendo un navegador en nuestro ordenador A y apuntando a “http://localhost:8000”.
Personalmente lo he probado simplemente con netcat entre 1 ordenador detrás de NAT y otro con conexión directa. En el que estaba detrás de NAT he ejecutado:
nc -l -p 80
De forma que netcat escucha por el puerto 80. Y en el otro ordenador, después de utilizar chownat tal y como he explicado me he conectado a dicho puerto mediante:
telnet localhost 8000
Y la conexión se ha establecido sin problemas (podia escribir texto en ambas terminales y se transmitia al otro extremo). Absolutamente fascitante ya que no he tenido que modificar nada del servidor que hace NAT ni de la configuración del firewall, lo que me hace pensar también que esto se podria utilizar como herramienta de ataque en redes privadas así que habrá que ir con cuidado 😉
Autor: marble
Siempre que desde los servidores se permitan conexiones salientes de los equipos de las redes por el puerto 2222 udp, no? Porque uno en casa seguramente eso no lo mira (o no le costaría cambiarlo en el LAN NAT que se les llama en el artículo, aunque puestos a cambiar no hace falta el invento este),
pero en una red de una empresa por ejemplo, que pinta el puerto udp 2222 abierto? No se me ocurre ninguna excusa para dejar que ningún empleado vaya enviando paquetes por ese puerto nada más que para hacer algo que no toca. Además, canta mucho en los logs 🙂
Por cierto, en:
por supuesto el servidor lo que hará será descartar automáticamente dicho tráfico ya que no sabrá a quien va dirigido
No estoy seguro. Si que sabe a quien va dirigido. Va dirigido a él. Le estás mandando paquetes al udp/2222 al NAT1. Y lo de que por ello los descartará automáticamente, pues oye, a saber, alomejor hace un ACCEPT, o un DROP o un REJECT. Al igual en ese puerto tiene un servidor de algo (aunque lo que haga con el paquete el NAT1 no importa en absoluto….bueno, quizás bajo ciertas circumstancias si que afectaría). Pero en fin, este paragrafo solo era para decir lo de que NAT1 si sabe a quien van esos paquetes. Le van a él.
—
bow before me, for I’m root
si el programari lliure no és la resposta, la pregunta és errònia
> Siempre que desde los servidores se permitan conexiones salientes de los equipos de las redes por el puerto 2222 udp, no?
El puerto 2222 también es configurable. Puedes buscar uno que si que permitan (e.g. 53 DNS, aunque necesitariamos ser root en el ordenador A ó B), normalmente no prohiben todos los puertos UDP… si es el caso esta claro que no puedes usar el programa.
>> por supuesto el servidor lo que hará será descartar automáticamente dicho tráfico ya que no sabrá a quien va dirigido
>
>No estoy seguro. Si que sabe a quien va dirigido. Va dirigido a él.
Evidentemente, va dirigido a esa IP pública. Normalmente en el puerto 2222 UDP no se tiene ningun servicio, si este fuese el caso pues iria a parar a la aplicación correspondiente. O si este puerto estubiese redirigido, pues entraria e iria a un PC interno concreto.
Te puedes encontrar en diversas situaciones, pero como regla general no va a haber ningun servicio en el 2222 UDP y el paquete será descartado (entiendase REJECT o DROP… no importa).
Hablo de que el servidor NAT no sabrá a quien va dirigido por que no tenemos pq tener una máquina GNU/Linux ahi corriendo servicios, podria ser un dispositivo hardware que solo se dedicase a enrutar, hacer de firewall y NAT. En este caso, sigue siendo evidente que los paquetes van a esa IP pública pero no se sabe a que PC interno.
—
Marble :: http://www.marblestation.com
Fent des de “Ordenador A” amb el ssh de manera més fàcil:
ssh -l usuari ip_pública_servidor_nat2 -L portlocal:ip_privada_ordenador_b:portdesti
D’esta manera, si volem accedir al port 80 de l’ordinador B, podem fer:
ssh -l jomateix ip_pública_servidor_nat2 -L 2000:ordenadorb:80
i després accedir amb el navegador a: http://localhost:2000
L’avantatge principal d’utilitzar ssh és que les comunicacions van encriptades, a més també es pot comprimir el flux de dades.
Jordi
Estas supossant que:
1) Tens el control sobre el servidor nat2
2) Tens un ssh configurat i un compte al servidor nat2
La gràcia de chownat es que no has de tindre aquestes condicions, imaginat a la xarxa interna de la Uni o d’una Campus Party o… 🙂
—
Marble :: http://www.marblestation.com
A mi no me funciona y eso que lo he probado todo.. el server manda los paquetes bien pero el cliente se para en binding a new socket, mirando el codigo se queda en el bucle de aceptar la conexion, no manda paquetes ni a equipos de mi red local, si me pudieras ayudar porque me sería muy util
gracias