Technorati Tags: pktmirror, redes, ethernet, networking, tunneling, ipsec, ip-in-ip, bug
He actualizado el software pktmirror, ya que tras casi 1 mes funcionando de forma ininterrumpida he descubierto un «pequeño» memory leak (de 1,5 GB) debido a un «malloc» que no liberaba después.
El paquete: pktmirror-v0.2.tar.gz.
Technorati Tags: Pakistán, YouTube, censura, routing, BGP
A lo mejor algunos notásteis una caída de YouTube el domingo. ¿Qué pasó? ¿Problemas con el pago del dominio? ¿Demasiado tráfico? ¿Un RAID roto? ¿Un DDoS? Casi lo último.
Ingredientes para un DoS mundial a YouTube:
Pues sí, señoras y señores, el gobierno pakistaní decidió bloquear YouTube en todo Pakistán, a causa de las manidas caricaturas de Mahoma, y no tuvo otra idea que configurar su AS con un par de cojones y metió en las tablas de BGP entradas que autoasignaban a dicho AS como autoridad para el rango de direcciones IP de YouTube.
Visto queda que la censura no es buena, como ya sabíamos. Pero ahora también hemos visto lo fácil que resulta sacar de Internet a una empresa (al menos durante unas horas) sin necesidad de tener una botnet.
Technorati Tags: pktmirror, redes, ethernet, networking, tunneling, ipsec, ip-in-ip
Para una demo del proyecto NOBEL 2, necesitábamos monitorizar unos paquetes RSVP que llegan de un router GMPLS. Como no tenemos acceso directo a dicho router, establecimos un túnel IP-in-IP (IP encapsulado sobre IP), y de ahí va a un túnel IPSec que nos conecta con el DCN del proyecto. Ambos túneles terminan en un servidor Linux, y el software de monitorización Clearpond corre bajo Windows. La topología en la siguiente figura:
La solución evidente para poder capturar los paquetes que llegan al servidor es poner un hub que conecte el servidor con una máquina Windows corriendo Clearpond, ¿verdad? Pues no exactamente, porque desde el hub se pueden ver paquetes IP encapsulados sobre IP y paquetes del túnel IPSec (que va cifrado, para más INRI). Y además de cerrado y sólo correr en Windows, el Clearpond sólo entiende paquetes IP normales, nada de paquetes encapsulados.
Por tanto, se nos ponía difícil la cosa. La solución de enchufar el PC con Windows directamente al router GMPLS tampoco servía, porque el túnel termina también en el propio router, por lo que habría que poner alguna máquina adicional más que terminara el túnel, y eso no es factible.
Así que la solución la dió otro compañero de TID (antes del CTTC), Fermín Galán, que nos sugirió utilizar libpcap para capturar los paquetes y reenviarlos al PC con Windows.
¿Y cómo reenviarlos? Evidente: usando sockets. RAW sockets para ser concretos. Pero tenemos un problema. Si ponemos la IP de origen y destino originales del paquete, las reglas de encaminamiento del servidor Linux mandarán el paquete por el túnel correspondiente, en lugar de mandarlo en bruto por la interfaz de red que ve el PC con Windows. Es decir, se vuelven a encapsular en sus túneles respectivos y estamos en las mismas, además de estar enviando los paquetes duplicados.
Otra opción sería enviarlos con las IPs origen y destino del servidor y del PC con Windows, pero existe el problema de que no sabemos si el software de monitorización toma las direcciones IP de la cabecera IP o del payload de RSVP, así que lo mismo eso no funciona.
La solución final: usar RAW Ethernet, y con la ayuda del software eth_send de Avelino Herrera, con algunas modificaciones (por ejemplo que ponga bien el campo tipo de protocolo de Ethernet), conseguí replicar los paquetes y enviarlos al PC con el Clearpond, tal cual los recibiría si no hubiera túneles de ningún tipo y haciendo que funcione a las mil maravillas el sistema de generación de la topología.
El código fuente del software: pktmirror-v0.1.tar.gz. Licenciado GPL v2.
Actualización 12/03/2008: nueva versión de pktmirror que soluciona un ligero memory leak.
Cuando uno quiere hacer un testbed de interconexión de varias máquinas y sólo dispone de una, hay que echarle imaginación. Pero si encima se quieren interconectar PCs con routers GMPLS y sólo se dispone de un PC, la cosa es mucho más divertida aún. Veamos cómo se hace para emular el comportamiento del Plano de Control de varios routers interconectados.
Ingredientes:
Proceso:
Ahora sólo falta emular las máquinas que van conectadas a los routers. Pero lo realmente interesante será hacerlo con routers de verdad. Bueno, y también hacer que dejen de aparecer mensajes de error en el gestor de conexiones.