bridge-utils y los puentes

1. Introducción
2. Interfaces tun/tap
3. Puente ethernet
4. OpenVPN
5. Virtualbox, OpenVPN y tráfico de vuelta
6. Servicios que dejan de funcionar
7. Referencias

1. Introducción

El motivo de escribir éste artículo es por los quebraderos de cabeza montandolo en la empresa de un colega. Y es que la necesidad de montar un puente en mi caso no viene de la necesidad de transferir tráfico de una red a otra, sino que en el servidor en cuestión había que implantar un sistema como VirtualBox y para que los guest tuvieran presencia en la LAN tenía dos posibilidades:

a) Mapear puertos del servidor con puertos del guest, lo cual no escala si tuviera varios guests que tienen los mismos servicios funcionando, tendrían que trabajar en diferentes puertos, y porque también quito esos puertos al servidor, y porque hay que abrir puertos en el servidor.....
b) Queremos que los guests tengan presencia en la LAN como si se tratara de una máquina física sin recurrir a historias de mapeos de puertos. Usando el concepto de bridge o puente.

Y me diréis ¿que tiene que ver VirtualBox con todo esto??? Pues la razón está en que para que un guest de VirtualBox tenga presencia en la LAN tenemos que crear un interfaz de red virtual, y el tráfico de este interfaz queremos que fluya hacia la LAN a través del interfaz físico del servidor. Antes de nada el concepto de guest hace referencia a la máquina virtualizada.

Explicaré este artículo aplicado a un caso práctico donde surge la necesidad de un bridge o puente como es en mi caso con VirtualBox.

2. Interfaces tun/tap

En la wikipedia hay una explicación sobre estos dos tipos de interfaces.

Estos interfaces son virtuales y la diferencia entre ellos está que mientras el interfaz tap trabaja a nivel de la capa de enlace, el interfaz tun lo hace en la capa de red. No voy aquí a explicar estos conceptos.

3. Puente ethernet

En el caso de VirtualBox se usan interfaces tap donde enganchamos cada guest, uno por cada guest, estos interfaces tap se les hace participar en un puente ethernet que actua como un switch, a dicho switch se conecta un interfaz físico como es el eth0.

El puente que creamos con bridge-utils sigue la nomenclatura br0, br1, etc.... la nomenclatura sigue el mismo patrón para eth0, eth1,.... o tap0, tap1.... o tun0, tun1.....

El fichero /etc/network/interfaces y su página man lo explica todo, dicho archivo interfaces y los scripts que giran en torno a este fichero entienden la definición del puente br0 donde participará eth0 y todos los tapX de los guest de VirtualBox que queramos, o interfaces tapX para otro fín que queramos... u otros interfaces ethX para conectar dos redes, aunque también podemos hacer uso del comando brctl para crear y administrar el puente.

Como el título dice se trata de un puente ethernet, aquí no hablaremos nada a nivel de IP, aunque la verdad y saltandonos los estándares podemos filtrar a nivel de IP con netfilter y con ebtables a nivel de mac,,, pero de éste último no hablaré en este artículo aunque lo he nombrado por si alguién lo necesitara.

Ejemplo de definición de un puente br0 donde participa el interfaz físico eth0 y el interfaz virtual tap0, destacar como dice la doc de bridge-utils que ni se os oscurra hacer esto sobre un servidor que accedeis por remoto porque os quedaréis sin conexión. Y es que el interfaz eth0 se levanta en modo promíscuo tragando todas las tramas ethernet y quien toma la ip es br0, el interfaz tap0 tampoco tiene ip asociada de eso se encargaría el interfaz del guest.

auto lo
iface lo inet loopback
auto tap0
iface tap0 inet manual 
up ifconfig $IFACE 0.0.0.0 up
down ifconfig $IFACE down
tunctl_user vboxuser

auto br0 iface br0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 bridge_ports eth0 tap0 bridge_maxwait 0

La verdad es que eth0 no me ha hecho falta ni definirlo, hubiera quedado igual que tap0 excepto el parámetro tunctl_user que es usado por la utilidad uml-util para que se pueda levantar el interfaz tap por un usuario sin privilegios. Importante es que tap0 esté definido antes que el bridge br0, observar que en bridge_port definimos todos los interfaces que van a participar del bridge.

Si queremos podemos jugar un poco con los comandos mas que manejar el archivo interfaces:

brctl 
Usage: brctl [commands]
commands:
	addbr     	<bridge>		add bridge
	delbr     	<bridge>		delete bridge
	addif     	<bridge> <device>	add interface to bridge
	delif     	<bridge> <device>	delete interface from bridge
	setageing 	<bridge> <time>		set ageing time
	setbridgeprio	<bridge> <prio>		set bridge priority
	setfd     	<bridge> <time>		set bridge forward delay
	sethello  	<bridge> <time>		set hello time
	setmaxage 	<bridge> <time>		set max message age
	setpathcost	<bridge> <port> <cost>	set path cost
	setportprio	<bridge> <port> <prio>	set port priority
	show      				show a list of bridges
	showmacs  	<bridge>		show a list of mac addrs
	showstp   	<bridge>		show bridge stp info
	stp       	<bridge> {on|off}	turn stp on/off

A posteriori podemos añadir nuevos interfaces al bridge con brctl addif, podemos ver el estado de bridge con brctl show, .....

4. OpenVPN

OpenVPN es un servicio que se nos recomienda hacerle trabajar en UDP por cuestiones de seguridad, aunque podemos hacerlo funcionar en TCP. Además se nos recomienda que trabaje con un interfaz tun, de modo que tanto en el servidor como cliente levantamos un interfaz tun por donde viaja el tráfico IP, para ello el cliente necesita conocer las rutas para reenviar dicho tráfico por tun0 y no por su eth0, esto se consigue propagando dichas rutas en el momento de la conexión y así el cliente no tiene que hacer nada.

Sólo un dato a tener en cuenta con la propagación de las rutas hacia la subred en la que trabaja la VPN, y es que por defecto se trata de una 10.8.0.0/24 para que no conincida con la situación de ningún cliente donde no se podría decir hacia donde enviar el tráfico, por ejemplo imaginaros que tanto en el cliente como VPN se trabajara con la misma subred 192.168.0.0./24...

Si a OpenVPN lo hacemos trabajar con un interfaz tap0 de modo que pasa el tráfico ethernet por el tunel y lo asociamos al bridge, ya tenemos otro caso de uso del bridge. Aunque la verdad en la doc de OpenVPN se indica el porqué de no usar un tunel ethernet entre otras por el hecho de no pasar todo el tráfico basura y controlar a nivel IP lo que nos interesa pasar por el tunel.

5. Virtualbox, OpenVPN y tráfico de vuelta

El artículo empezó porque quería tener virtualizados a diferentes guest en VirtualBox y que estos tuvieran presencia en la LAN. También hemos descrito un caso de uso del bridge ethernet con OpenVPN, el cuál a su vez puede montar un tunel ip o ethernet usando interfaz tun o tap respectivamente.

Pero vamos a explicar una situación típica con el tráfico de red.

Cliente OpenVPN------>Servidor VPN------>Host LAN/Guest VirtualBox------>Default Gateway
tun0---------------------->br0/tun0--------------->eth0/tap0
<-------------------------2ª gateway<-------------Tráfico de vuelta

El tráfico gracias a las rutas que se propagan en la conexión VPN entra por tun0 del cliente y sale por tun0 del servidor, se hace forward y sale por br0, llega al eth0 del cliente en la LAN.

Si OpenVPN no es el gateway por defecto en la LAN, ni el Host LAN ni el Guest VirtualBox llevarán el tráfico de vuelta hasta OpenVPN sino a su default gateway. Tenemos tres posibilidades:

a) Añadir la ruta correspondiente al gateway para que enrute el tráfico al servidor OpenVPN.
b) Propagar por dhcp un segundo gateway que sería el servidor OpenVPN.
c) Añadir en la configuración de cada equipo de la LAN a mano una ruta asignando un segundo gateway.

Otro problema común al configurar un bridge es referente a que tenmos reglas en el firewall que hacen referencia al interfaz eth0, hay que cambiarlos para que represente la nueva situación especificando el br0, tener en cuenta el forward entre interfaces.

6. Servicios que dejan de funcionar

Al igual que el tráfico de vuelta nunca le echamos cuenta, o las reglas del firewall del servidor que tampoco le echamos cuenta debemos de estar atentos también al firewall en nuestro equipo cliente ya que tenemos que dejar pasar el tráfico por el interfaz tun0.

Un servicio que dejó de funcionar cuando cambié la configuración del servidor para que usara un bridge ethernet y no dió la cara hasta el reinicio del servicio fué el caso de dhcpd. Tiene un fichero en /etc/default/dhcpd3-server donde define el interfaz sobre el que trabajo y hay que cambiarlo de eth0 a br0.

Hay que repasar todos aquellos servicios que estén asociados al interfaz ethernet eth0 y cambiarlo. En definitiva os recomiendo que después de configurar el bridge le demos un repaso general al sistema ya que nos llevaremos mas de una sorpresa.