Disclaimer para Telefonica y TMobile: El siguiente post es con fines educativos y tecnologicos, “cuidadito con lo que haceis que ya sois mayorcitos”

Como he puesto aqui sienes y sienes de veces, a veces me parece que me paso media vida en los aeropuertos, entre lo que vuelo y la cantidad de horas que tienes que echar entre facturacion, embarque y recogida de maletas uno termina acostumbrandose a las esperas y a aprovechar el tiempo. Siempre vuelo rodeado de cacharros, generalmente con wifi y linux (la zaurus, portatiles, etc). En los aeropuertos suele haber wifi, generalmente propiedad de alguna telefonica y proveedor y casi siempre de pago (hay jugosas excepciones, como la sala de llegadas internacionales del aeropuerto de San Francisco o la cafeteria del aeropuerto de Jerez). Los precios son excesivos y estan pensados para ejecutivos, road warriors y demas cascarrias a las que las que la conexion les sale gratis porque se la paga la empresa, a la que no le importa pagar 60 dolares por dia de Internet.

Es cuanto menos una irracionalidad (y casi una inmoralidad) que nos cobren por la conexion de red pero no por el agua o la electricidad dado el coste minimo que tiene el transporte de esa conexion, las tarifas de los aeropuertos recuerdan a los que costaba conectarse a Internet en la Espagna pre-infovia y somos muchos los que, aun pudiendo, decidimos no dar un duro al proveedor de turno con tal de que no se nos quede una tremenda cara de gilipollas durante todo el vuelo.

Si uno quiere acceder gratis a esas conexiones lo primero que a uno se le pasa por la cabeza es leer con ethereal las direcciones MAC de los usuarios que estan conectados a la red y cambiarse la suya propia por uno de los usuarios existentes “a ver que pasa”, esto nunca lo he realizado y tengo muchas discusiones con compagneros sobre la viabilidad de este metodo.

De todos modos, a poco que nos dejen un uso infimo de la conexion podemos aprovechar para crear tuneles TCP usando los servicios que tenamos disponibles, la cosa es observar la red, ver que se nos deja hacer y poner un servidor “nuestro” que nos tunele servicios desde lo que se nos deja hacia la red TCP. Observando los nodos de pago se ve que casi todos nos permiten hacer dos tipos de tarea: hacer una peticion DNS a un servidor cualquiera y/o usar ICMP para hacer ping a alguna maquina de la red. La teoria, de nuevo, es poner un servidor “nuestro” que responda a peticiones DNS y/o ICMP y tunelear TCP desde ese tipo de peticiones.
Lo que sigue sirve para sistemas para sistemas Linux, la mayoria de ellos pueden usarse con varios sabores de BSD. No voy a entrar en mucho detalle en configuraciones ya que estan mas que explicadas en las paginas de los proyectos, en lugar de eso explicare como es la arquitectura de los dos diferentes sistemas de tunelado y respondere a las dudas que tengais (por jabber o mail por ejemplo, mis datos estan en el weblog)

Tuneles DNS: NSTX

Para ver si la red del aeropuerto nos deja usar un DNS cualquiera cambiaremos el nameserver del fichero /etc/resolv.conf a a la ip de algun servidor DNS diferente al que nos ha dado el DHCP de la red, el que yo suelo probar, (y la que uso aqui en casa porque es la de mi proveedor de cable) que es facil de memorizar: 4.2.2.2 (.3, .4, ….) que corresponde al DNS de comcast. A partir de ahi podemos usar los comandos ping, host, dig (o cualquiera que use el DNS) a cualquier maquina (yahoo.es por ejemplo) y si vemos que la maquina es capaz de convertir el dominio por su direccion ip, podremos crear un tunel DNS sin problemas.

Basicamente la teoria de este sistema es encapsular trafico TCP/IP en llamadas DNS (para enviar) y recibir las respuestas como ‘nombres de dominio” a la vuelta. Tanto las llamadas como los nombres de dominio que recibiremos seran mas falsos que un judas de plastico y tendran la informacion de (trozos) de los paquetes que estemos intentando enviar. Las respuestas de nuestro cliente seran peticiones para saber la direccion IP de KJhjh33.dd_2sT-XXT.dAAoi_f.mydnstunnel.org, por ejemplo y la respuesta (el paquete de vuelta) nos vendra dada en el campo TXT, con la misma estructura y sin el menor sentido (aparente).

Para nuestro querido proveedor de aeropuerto que deseaba forrarse con nosotros todo se vera como inocentes peticiones de dominio, pero en realidad estaremos mapeando paquetes TCP/IP en llamadas y respuestas DNS. Hay varios problemas a solventar, el primero es que DNS va por UDP y no TCP (con lo que hay que construir un mecanismo de verificacion) y que las llamadas DNS tiene una longitud maxima de 512kb, por lo que hay que partir nuestro paquete TCP/IP en para adecuarlo al tagmano maximo permitido.

Ha varios proyectos llamados NSTX, uno de ellos salio en Slashdot por el agno 2000 y tuvo mucha aceptacion, de todos modos por lo que he probado el mejor sistema para crear tuneles por DNS es el creado por Thomer M. Gil (un doctorado del MIT, si mirais un poco en su pagina tiene una seccion dedicada al vi muy simpatica). Este proyecto es el mas transparente de todos, nos crea dos interfaces tun en las maquinas cliente y servidor que mapean los paquetes que se le mandan sobre DNS, haciendo que nos olvidemos de todo.
El sistema de Gil requiere tener dos maquinas, un servidor DNS ‘real’ que podamos configurar y otro ‘falso’ con NSTX escuchando en el puerto 53 (el usado por el DNS), si el segundo ordenador corre alguna variante de Debian (como Ubuntu), el paquete deberia estar disponible con apt-get. Tanto la maquina que corra el servidor como el cliente que usamos usaran interfaces tun para comunicar los programas, por lo que los modulos tun/tap deberan estar compilados y metidos en el kernel (si tenemos uno de la serie 2.6, no hay problema). Si usamos maquinas debian, lo dicho, instalarlo es coser y cantar, la configuracion viene en la pagina de Thomer, aunque necesita trastear un poco con las iptables, es muy clarita y siempre suele salir a la primera tal y como la pone el autor.

Tuneles Ping o ICMP

Hay algunos sistemas que bloquean peticiones DNS (los menos) pero permiten hacer ping a maquinas fuera de la red en la que estamos. Comprobarlo es trivial (ping goatse.cx por ejemplo).

El sistema, cuya pagina se encuentra aqui se centra en la idea de tener un proxy controlado por nosotros y un cliente (nuestro laptop por ejemplo). Ambas maquinas se enviaran paquetes de peticion echo (tipo 8 para el cliente tipo 0 para el servidor) que son los tipicas llamadas ping que hacemos desde la linea de comandos. El cliente envia las peticiones al proxy que las ejecutara y las devolvera de nuevo al cliente como respuestas al chorro constante de pings que se vera desde fuera de nuestro tunel. El protocolo ICMP tiene un campo de datos (despues de una logica cabecera) que deja suficiente espacio para que metamos la informacion del paquete TCP/IP que queremos encapsular. El sistema de control de congestiones y el sistema de comprobacion de perdidas de paquetes es muy muy basico (el autor esta currandoselo un poco mas) y hace que el tunel no vaya demasiado rapido (el autor ha conseguido velocidades de 150k de bajada y 50 de subida), asi mismo se notan bajadas y subidas de velocidad sin sentido aparente (la causa es la mala gestion de congestion, com dije), incluso de algunos cortes de conexion, pero en general va bastante bien.

La parte cliente y la del proxy estan en la pagina de autor en codigo fuente e instalables RPM y DEB, el modus operandi del mismo es un poco diferente al tunel de DNS (aqui no hay un interface nuevo) y nos pide que indiquemos la maquina que queremos que el proxy nos alcance, por ejemplo si queremos hacer ssh a goatse.cx en la parte del cliente haremos

sudo ./ptunnel -p miservidor.com -lp 8000 -da goatse.cx -dp 22

y entraremos a goatse haciendo un ssh a nuestra propia maquina (localhost) por el puerto especificado (8000)

ssh -p 8000 localhost

ojo que casi siempre ssh avisa de que alguien intenta choricearnos las claves (un ataque man-in-the-middle) por lo que es necesario quitar las claves de .ssh/known_hosts

A mas de uno se le habra encendido la luz con el ssh, si algo nos permite el protocolo ssh es la creacion automatica de proxys socks encriptados usando el protocolo (deberia dejar otro post para las maravillas del ssh y como conseguir anonimato mediante ese comando), por lo que, brevemente, si queremos navegar con el firefox usaremos

ssh -D 1080 -p 8000 localhost

y configuraremos el

firefox con el proxy socks (5) apuntando a localhost:1080 para la nevagacion.

Ambos sistemas de tunelado nos serviran para salir de algun apuro sin tener que pagar el impuesto revolucionario de ciertos operadores, no conseguiremos la velocidad que conseguiriamos con una conexion normal (no espereis bajaros peliculas mientras esperais el vuelo, por ejemplo), pero si que suele dar una conexion muy resultona. Sugiero usarla conjuntamente con una sesion screen en un servidor remoto, y dentro de ese screen tener ‘tabs’ abiertas con el correo/irc/messenger/web, etc…. ya que si perdemos la conexion podremos volver a reengancharnos sin perder lo que estabamos viendo o las conversaciones que estabamos teniendo. Si alguien no sabe lo que es screen, en suburbia hay un articulito que traduje hace mucho tiempo sobre las bondades y las instrucciones de uso de ese gran programa.
Lo recomiendo encarecidamente (no solo para estas movidas, yo lo uso a todas horas)
Por ultimo, estos metodos pueden ser (y son, me consta) usados en paises donde no hay libertad de prensa ni de pensamiento e Internet, como muchos mas sistemas de comunicacion, es constantemente bloqueado y monitorizado. Aunque solo sea por eso, ambos proyectos merecen muchisima ayuda y colaboracion, aunque sean con cositas tan simples como darlos a conocer mediante una entradita en este blog.

Buen vuelo !

Links

TCP sobre DNS

TCP sobre PING