Cómo ya vimos es posts anteriores, Open vSwitch és un software de virtualización de redes pensado sobretodo para la virtualización en plataformas Linux como Xen o KVM. Después de estar trasteando un buen tiempo con OpenNebula pensamos que seria una muy buena idea añadirle el soporte que viene integrado con Open vSwitch. Al añadir el driver para este, pero, nos encontramos con que el driver no está acabado del todo y que nos quedábamos sin algunas de las funcionalidades de red de OpenNebula.
Así pues, vamos a empezar una serie de posts con los que iremos viendo algunas de las deficiencias que se han encontrado a los drivers de OpenNebula para Open vSwitch y las soluciones que le hemos aplicado al driver en cuestión. En este primer post vamos a ver un bug que se ha encontrado en el driver y la solución que se ha aplicado. Tener en cuenta que en la versión 4.0 de OpenNebula este bug ya a sido solucionado. En posts futuros veremos como se ha añadido soporte para filtraje de rangos de puertos y cómo hacer que el tráfico de las máquinas virtuales sea descartado en caso de que la IP sea falseada en las máquinas virtuales.
OpenNebula asigna la MAC a las interfícies de las máquinas virtuales según la IP que asignamos, entonces si hacemos dos redes con coincidencia de IPs en diferentes VLANs es probable que las MACs de dos máquinas virtuales coincidan están en la misma máquina física.
Para entender bien el bug, en primer lugar se han hecho pruebas de si este caso afecta al comportamiento de la red. Se han creado dos redes taggeadas diferentes con el mismo direccionamiento, así pues cuando creemos interfícies de cada una de las redes sobre el bridge estas estarán taggeadas con una etiqueta diferente.
Se han creado 4 máquinas virtuales:
1 y 2 – con VLAN con etiqueta 1. La primera tiene la IP 192.168.2.1 y MAC 02:00:c0:a8:02:01 y la segunda tiene la IP 192.168.2.2 y MAC 02:00:c0:a8:02:02
3 y 4 – con VLAN con etiqueta 2. La tercera tiene la IP 192.168.2.1 y MAC 02:00:c0:a8:02:01 y la tercera tiene la IP 192.168.2.2 y MAC 02:00: c0: a8: 02:02
Vemos pues que las máquinas 1 y 3 y las máquinas 2 y 4 coinciden en la MAC, para la prueba hemos puesto la máquina 1 y 3 en el mismo nodo físico y la 2 y la 4 en otro las dos.
Una vez hecho esto, desde la máquina 1 hacemos un ping a la IP 192.168.2.2 mientras en las máquinas 2 y 4 hacemos un tcpdump, la salida del tcpdump en la máquina 2 es:
20:27:36.768326 ARP, Request who-has 192.168.2.2 tell 192.168.2.1, length 46 20:27:36.768336 ARP, Reply 192.168.2.2 is-at 2:00: c0: a8: 02:02, length 28 20:27:36.769355 IP 192.168.2.1> 192.168.2.2: ICMP echo request, y 46852, seq 1, length 64 20:27:36.769390 IP 192.168.2.2> 192.168.2.1: ICMP echo reply, id 46852, seq 1, length 64
En la máquina 4 el tcpdump no nos da ninguna salida.
Así pues vemos como a pesar de tener interfaces con la misma MAC no afecta al correcto funcionamiento del Open vSwitch, ya que están taggeadas diferente y el Open vSwitch aunque detecta MACs duplicadas sabe redirigir el tráfico según la VLAN a la que pertenece cada paquete de red .
Si miramos el driver de Open vSwitch en el fichero /var/lib/one/remotes/vnm/ovswitch/OpenvSwitch.rb, veremos que las reglas de firewalling se aplican para la MAC, suponiendo que queremos filtrar el puerto 1 para la máquina con MAC <mac>, el comando que se ejecuta en las máquinas físicas es como sigue:
sudo ovs-ofctl add-flow br32 tcp,dl_dst=<mac>,tp_dst=0x1,actions=drop
Vemos como cuando se aplica el filtraje, sólo se tiene en cuenta la MAC, así si aplicamos filtros sobre una máquina virtual y tenemos otra con la misma MAC, se aplicará sobre las dos máquinas al mismo tiempo, por lo que los filtros aplicados por un usuario podrían afectar a los demás.
Hemos hecho la misma prueba que en el apartado anterior y efectivamente hemos visto que al aplicar un firewall sobre una MV si tenemos otra MV en la misma red que tenga la misma MAC (aunque esté en otra VLAN) aplica las reglas para a las dos máquinas.
Para solventar este problema se han modificado las reglas añadiendo el tag dl_vlan al comando ovs-ofctl. Se ha probado y efectivamente, como las redes por fuerza tienen diferente tag de VLAN, funciona correctamente.
Hay que tener en cuenta que desde el Sunstone es posible crear redes sin que estén taggeadas. En este caso si que podríamos tener un problema, ya que si las redes no tienen ninguna etiqueta, no están en ninguna VLAN, entonces si que tenemos el problema explicado anteriormente.
El comando anterior, una vez arreglado este bug quedaría de la siguiente forma, suponiendo que la interfaz de la máquina virtual está en la vlan 3001:
sudo ovs-ofctl add-flow br32 tcp,dl_vlan=3001,dl_dst=<mac>,tp_dst=0x1,actions=drop
En este y este enlace podemos ver el seguimiento del bug, en el segundo enlace podemos también descargarnos el driver para OpenNebula modificado.
Eso es todo por este post, en los siguientes, tal y como ya hemos avanzado al principio veremos cómo permitir el filtraje de puertos por rangos mediante Open vSwitch y añadir la funcionalidad en los mismos drivers para no permitir que las máquinas virtuales puedan hacer IP-Spoofing.
Un saludo clouderos! 😉
