El Blog de Marcelo!

De a poquito y con el reset del año, vuelven las ganas de leer y aprender sobre temas nuevos para escribir algo de texto y código como output de lo aprendido. En este caso, y para complementar aquello que escribí sobre HTTP/2, estoy preparando algo similar pero sobre QUIC como protocolo de transporte y HTTP/3 como protocolo de aplicación sobre él.

Ambos son Internet Standard desde hace muy poco tiempo (quic, http/3) y vienen y/o dependen de un paquete de otros protocolos y especificaciones que no son poca cosa.

Aún así, mi idea es describir sus conceptos fundamentales en español, como para que lo entienda un estudiante de una asignatura de redes de una Universidad cualquiera; analizar sus pros y cons, y por último dejar algo de código de ejemplo como para poder entender desde el punto de vista de un programador dónde tiene lugar para hacer un aporte y dónde no.

En este mes de febrero tuve la suerte de llevar adelante en la UNLu un breve pero conciso taller de programación de sockets basado en Python. Dejo los slides, ejemplos de código y ejercicios planteados en el apartado de Charlas de mi blog, y en este post.

Agenda:

• Clase 1: Introducción Sockets API. Modelo OSI, entornos de ejecución.Introducción a Python. Socket API para UDP. Ejercicios.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.
• Clase 2: Socket API para TCP. Código de ejemplo y ejercicios.
  • Descargar en Formato ODP / Formato PDF.
• Clase 3: Multiprogramación, concurrencia, paralelismo. Syscall fork() y relacionados. Ejemplos de servidor multiproceso. Procesos vs. Threads.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.
• Clase 4: Sockets asincrónicos. Modelo de trabajo, syscall select(). Ejemplos de código. Introducción a Scapy.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.

¡Saludos!

Investigando herramientas de simulación/emulación de redes con fines educativos, un amigo pasó esta página, bastante nutrida por cierto, con un listado de simuladores/emuladores de red, recomendando probar CORE.

C.O.R.E., acrónimo de Common Open Research Environment, fue un proyecto inicialmente de Boeing (sí, la de los aviones) y que ahora es sponsoreado por el Laboratorio de Investigación Naval de los Estados Unidos. Le dediqué un rato a revisar qué tal funcionaba, y aquí está lo que pude probar.

A priori, resulta que la última versión (4.8) está en los repos de Ubuntu 16.04, por lo que fue fácil la instalación [1]:

marcelo@marcelo-notebook:~$ apt-cache search core-network
 core-network - intuitive network emulator that interacts with real nets (metapackage)
 core-network-daemon - intuitive network emulator that interacts with real nets (daemon)
 core-network-gui - intuitive network emulator that interacts with real nets (GUI)

Se instalan esos paquetes y listo el pollo, las dependencias son básicas (TCL/TK y quagga):

marcelo@marcelo-notebook:~$ sudo apt install core-network core-network-gui
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias 
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes adicionales:
 core-network-daemon libev4 libtcl8.5 libtk-img libtk8.5 quagga tcl8.5 tk8.5
Paquetes sugeridos:
 libtk-img-doc snmpd tcl-tclreadline
Se instalarán los siguientes paquetes NUEVOS:
 core-network core-network-daemon core-network-gui libev4 libtcl8.5 libtk-img libtk8.5 quagga tcl8.5 tk8.5
0 actualizados, 10 nuevos se instalarán, 0 para eliminar y 2 no actualizados.
Se necesita descargar 3.905 kB de archivos.
Se utilizarán 16,4 MB de espacio de disco adicional después de esta operación.
¿Desea continuar? [S/n]

Usarlo es tanto como ejecutar «core-gui» y empezar a armar el mapa de la red tal como se ve en el video de la página que citó Mauro:

Vista de Red – CORE

El direccionamiento lo hace automáticamente (aunque es configurable, haciéndole doble click a cada nodo):

… y la configuración del ruteo se hace sola (ver más abajo cómo), por lo que luego de armar esa red sencilla, ambos hosts («PC» y «Server») se ven automáticamente.

Luego de armar la red, se le da al botón de «Play» y se ejecuta todo. Todos los nodos son Linux (nada de emulación routers Cisco ni nada como sucede con GNS3), y acá viene lo interesante:

• Todos son containers (LXC) del mismo host de uno, pero sin estar en un chroot (?!?),
• Es extremadamente rápido gracias a LXC, pero «raro» ya que todo corre en el mismo filesystem de la máquina de uno (puedo ir a mi home directamente desde cada nodo).
• Dado que es un container, todos los kernels guest son los mismos del host.
• ¡El software que se ejecuta es el mismo del host! Es decir, si digo que este nodo va a tener Apache (servicio «HTTP»), hay que instalar el paquete apache2 en el host, no en el guest. No hay imagen de máquina virtual ni nada por el estilo como pasa con otros emuladores.
• El directorio que te abre al entrar a cada guest es/tmp/pycore.<PID>/<nombredelhost>.conf/
• La configuración de los servicios/apps que va a usar en cada host la genera el entorno antes de darle «Play» en /tmp/pycore.<PID>/<nombredelhost>.conf/, por ejemplo:

Uno puede ir y editar los archivos en el directorio etc.apache2/ que generó el sistema una vez que se le dio ejecución, o puede hacerlo antes, tocando en el botón «Services» de la configuración del host:

Y luego en el ícono de llave inglesa:
Este es un ps desde el guest Server:

root@Server:/tmp/pycore.34211/Server.conf# ps faxu
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 9676 1708 ? S 12:20 0:00 /usr/sbin/vnoded -v -c /tmp/pycore.34211/Server -l /tmp/pycore.34211/Server.log -p /tmp/pycore.34211/Server.pid -C /tmp/pycore.34211/Server.conf
root 46 0.0 0.0 65508 3096 ? Ss 12:20 0:00 /usr/sbin/sshd -f /etc/ssh/sshd_config
root 52 0.0 0.0 56680 3772 ? Ss 12:20 0:00 /usr/sbin/apache2 -k start
www-data 53 0.0 0.0 411412 3504 ? Sl 12:20 0:00 \_ /usr/sbin/apache2 -k start
www-data 54 0.0 0.0 411412 3504 ? Sl 12:20 0:00 \_ /usr/sbin/apache2 -k start
root 110 0.0 0.0 23848 3968 pts/19 Ss 12:20 0:00 /bin/bash
root 236 0.0 0.0 39932 3316 pts/19 R+ 12:22 0:00 \_ ps faxu
root@Server:/tmp/pycore.34211/Server.conf#

Este es el running-config generado por core-network de un router (r1), entrando a Quagga con vtysh:Así que ahí vemos que define OSPF automáticamente:

Respecto a si se pueden guardar/cargar laboratorios completos, sí se puede, en el formato «imn» (ya que CORE es un fork de Imunes, y heredó su formato). Algo muy interesante es que se puede configurar el QoS de cada link, haciéndole doble click a cada línea (no lo probé):

Y que te grafica el ancho de banda en tiempo real de la red:

Por último, para hacer capturas de tráfico es bastante sencillo, probé dos opciones:

1. Se corre en cada nodo que se desea un tcpdump guardando el tráfico, queda en el «home» de cada container guest (/tmp/pycore.<PID>/<nombredelhost>.conf/), y uno desde el host directamente ejecuta Wireshark y lo abre.
2. Pude guardar todo el tráfico de la red en una única captura (esto, con netkit, no lo pudimos hacer de forma directa). Para ello, primero se arranca el entorno de simulación; esto hace que se creen dinámicamente los bridges a nivel de host y las interfaces virtuales de cada container, adjuntas a cada bridge (el virbr0 de la captura es de Virtualbox, ignórenlo):

Y bueno, para hacer la captura de toda la red al mismo tiempo, hay que decirle a Wireshark que capture en todos los bridges:

Filtré porque aparece tráfico OSPF todo el tiempo, lógicamente. Es cuestión de desactivarlo por defecto (configurando el servicio Quagga/Zebra). Un detalle de capturar así es que hay que ordenar por tiempo, porque el packet number queda desordenado. Pero ordenando por tiempo, lo seguí y aparentemente (hice un ping, nada más) el orden se mantiene (el «reloj» sería el host).

El manual está acá, parece que se pueden hacer muchísimas cosas más (entornos distribuidos, scripting automatizado en Python, etc.):
https://downloads.pf.itd.nrl.navy.mil/docs/core/core-html/index.html

Parece ser una muy buena herramienta para simular entornos de red, practicar y aprender sobre protocolos.

[1] Resulta que hace poco lo sacaron de Debian/Ubuntu, porque claro, el entorno gráfico se ejecuta como usuario normal, pero al abrir la consola de cualquier nodo que uno creó entra a la VM como root (y recuerden que no se está dentro de un chroot, con lo cual es root en el host con acceso al filesystem):

https://github.com/coreemu/core/issues/117

No lo solucionaron, entonces Debian los sacó, por ende no está en Debian Stretch. Igual maintainer del paquete tiene un repositorio personal para Debian/Ubuntu:

http://eriberto.pro.br/core/

Saludos

Les comparto el documento que armé dentro del marco del grupo de Teleinformática y Redes de la Universidad Nacional de Luján sobre el protocolo HTTP/2, a modo de recopilación, traducción y simplificación de todo lo que anda dando vueltas en la web. La idea es ir actualizándolo y completándolo a medida que pase el tiempo.

Dejo el link para bajarlo en PDF.

Se aceptan sugerencias, comentarios y críticas, por qué no. 🙂

Saludos

Una de las cosas que me sorprendió de la versión de Apache 2.4.18 incluida en Ubuntu 16.04 (y también en Ubuntu 16.10) es que el módulo mod_http2 no está habilitado por ser considerado «experimental» por el proyecto Apache.

Discusiones de si debe estar o no al margen, esta característica funciona mayormente bien y no tiene fallas importantes. En mi caso evalué un par de alternativas:

• Compilar un server nuevo desde los fuentes es poco práctico, ya que la integración de Apache lograda por el empaquetado de Debian/Ubuntu es mala o dificultosa como mínimo, además de tener que compilar por futuras actualizaciones de seguridad.
• Confiar en un repositorio PPA ajeno (como indican otros posts) también es un problema, más aún bajo ciertos entornos.

Es por esto que, buscando una alternativa diferente, encontré una manera relativamente fácil, rápida y «con actualizaciones» de habilitar el módulo HTTP/2 sobre el mismo Apache 2.4.18 que trae Ubuntu 16.04/16.10.

Dado que el módulo http2 se incluye en los fuentes, es posible compilarlo y copiarlo nuevamente a la instalación de Apache creada por el paquete Ubuntu. Como requisito, hay que tener los repositorios deb-src habilitados en el archivo /etc/apt/sources.list.

Luego se debe instalar libnghttp2-dev, descargar el paquete fuente de apache2 y compilarlo sin hacer ningún cambio. Los comandos para hacer esto son, como usuario con permisos de sudo sobre el sistema:

$ sudo apt-get install libnghttp2-dev
$ mkdir apache2
$ cd apache2
$ apt-get source apache2
$ sudo apt-get build-dep apache2
$ cd apache-2.4.18
$ fakeroot debian/rules binary

Después, copiar el módulo compilado (mod_http2.so) al directorio de módulos del apache, crear un archivo .load en /etc/apache2/mods-available y ejecutar a2enmod http2 para que Apache lo cargue. Luego, se reinicia el servicio y listo.

$ sudo cp debian/apache2-bin/usr/lib/apache2/modules/mod_http2.so /usr/lib/apache2/modules/
$ cat << EOF > /tmp/http2.load
LoadModule http2_module /usr/lib/apache2/modules/mod_http2.so
<IfModule http2_module>
  LogLevel http2:info
</IfModule>
EOF
$ sudo cp /tmp/http2.load /etc/apache2/mods-available/http2.load
$ sudo a2enmod http2
$ sudo service apache2 restart

Y listo. Luego resta configurar algunas de las opciones del módulo e incorporarlo en los VirtualHosts que necesitemos, indicando «Protocols h2 http/1.1».

Para más info de cómo instalarlo, leer acá.

Saludos