Para poder trabajar con VLANs tageadas en un servidor Red Hat Enterprise 6.0 con múltiples alias de red, tendremos que esforzarnos un poco. En mi caso, he partido de un servidor con una única tarjeta de red (eth0) configurada con 10 alias, todo IPs del mismo rango, del siguiente estilo:
eth0:0 192.168.1.2
eth0:1 192.168.1.3
...
eth0:10 192.168.1.12
Por supuesto, el servidor contaba con un default gateway configurado en cada uno de los alias:
GATEWAY=192.168.1.1
Con este servidor en producción, y con mucho sudor frío, he pasado a configurar el rango 10.0.0.2-10.0.0.25 en el servidor, con default gateway 10.0.0.1, todo perteneciente a la VLAN 30, y todo tageado, también usando la misma interfaz eth0, y lo más importante, manteniendo la configuración de red original (es decir, acabaremos teniendo el servidor configurado para trabajar con 2 rangos de IPs diferentes, uno de ellos perteneciente a la VLAN 30).
Por cierto, si estás pensando en seguir los pasos aquí descritos en un servidor en producción, te recomendaría testearlos primero en un entorno de test, y tener un plan B para recuperar la conectividad con el servidor en caso de cometer algún error.
Configuración del soporte VLAN
Lo primero que tendremos que hacer, es asegurarnos que el servidor tiene soporte para trabajar con VLANs tageadas:
[root@myServer]# lsmod | grep 8021q
Si no hay respuesta tras ejecutar el comando anterior, deberemos cargar el módulo 8021q con el siguiente comando:
[root@myServer]# modprobe 8021q
Tras ello, podremos verificar como ahora sí estará cargado el soporte para VLANs tageadas:
[root@myServer]# lsmod | grep 8021q
8021q 24221 0
garp 7310 1 8021q
Para que el nuevo módulo se cargue tras cada reinicio, deberemos seguir la documentación oficial de Red Hat 6, y crear un fichero para dicho propósito:
[root@myServer]# touch /etc/sysconfig/modules/8021q.modules
[root@myServer]# chmod u+x /etc/sysconfig/modules/8021q.modules
[root@myServer]# cat /etc/sysconfig/modules/8021q.modules
#!/bin/sh
exec /sbin/modprobe 8021q >/dev/null 2>&1
NOTA: Ésto mismo, también me ha funcionado bien en un antiguo servidor Fedora 13.
Configuración de las interficies de red
En entornos del tipo Red Hat, una interfaz que pertenece a la VLAN con ID 30, se configurará mediante un fichero en /etc/sysconfig/network-scripts con nombre «interfaz».»VlanID» En nuestro caso, crearemos una interfaz de este estilo para la primera IP del nuevo rango:
[root@myServer]# vi /etc/sysconfig/network-scripts/ifcfg-eth0.30
DEVICE=eth0.30
VLAN=yes
BOOTPROTO=none
TYPE=Ethernet
IPADDR=10.0.0.2
NETMASK=255.255.255.0
IPV6INIT=no
USERCTL=no
Una vez tengamos lista la interfaz, pasaremos a configurar el resto del rango, creando un fichero de rango para nuestra recién creada interfaz:
[root@myServer]# vi /etc/sysconfig/network-scripts/ifcfg-eth0.30-range0
IPADDR_START=10.0.0.3
IPADDR_END=10.0.0.25
CLONENUM_START=20
NETMASK=255.255.255.0
Con ésto, habremos configurado el rango de IPs 10.0.0.2-10.0.0.25 como alias de nuestra interfaz eth0, todas trabajando con la VLAN tageada con VLANID 30.
Si reiniciamos la red veremos como nos aparecen los nuevos alias de nuestra interfasz eth0. Hay que tener en cuenta, que en el ejemplo, se ha especificado como CLONENUM_START=20, lo cual significa que los nuevos alias se empezarán a crear a partir del alias 20, tal que así eth0.30:20, eth0.30:21, etc.
[root@myServer]# service network restart
Ruta estática para el nuevo gateway
Ahora que tenemos el soporte VLAN con el módulo 8021q, y hemos definido el nuevo rango de IPs como alias pertenecientes a la VLAN 30, con todo el tráfico tageado, faltará definir las rutas estáticas para que el nuevo rango de IPs salga por su gateway (10.0.0.1) en lugar de por el default gateway del server (192.168.1.1). A ésto se le conoce como «source based policy routing«, puesto que el enrutado se hace basandose en la red origen en lugar de en la red destino.
Primero, deberemos crear una nueva tabla de rutas para la nueva VLAN:
[root@myServer]# echo "300 vlan30" >> /etc/iproute2/rt_tables
[root@myServer]# cat /etc/iproute2/rt_tables
...
300 vlan30
A continuación crearemos una regla para que todo el tráfico que tenga como origen la nueva red que hemos creado (10.0.0.0/24) mire la nueva tabla de rutas:
[root@myServer]# ip rule add from 10.0.0.0/24 lookup vlan30
[root@myServer]# ip rule list
0: from all lookup local
32765: from 10.0.0.0/24 lookup vlan30
32766: from all lookup main
32767: from all lookup default
Finalmente, llenaremos la nueva tabla de rutas con el default gateway para el nuevo rango:
[root@myServer]# ip route add default via 10.0.0.1 dev eth0.30 table vlan30
[root@myServer]# ip route list table vlan30
default via 10.0.0.1 dev eth0.30
Como se puede ver, en la instrucción anterior indicamos que el default gateway para la tabla vlan30 corresponde con la IP 10.0.0.1, y sale a través de la nueva interfaz de red eth0.30. De esta manera, el tráfico saldrá por la interfaz configurada para tagear el tráfico con el VLANID 30.
En este punto, ya podremos trabajar con nuestro anterior rango de IPs del servidor, 192.168.1.0/24, además de con el nuevo rango 10.0.0.1 que saldrá tageado con VLANID 30. Sin embargo, aun no habremos acabado, pues estos cambios en las tablas de rutas no son persistentes.
Para hacer estos cambios permanentes, tendremos que crear un fichero para la regla, y otro para la ruta. Respecto a la regla, lo crearemos así:
[root@myServer]# vi /etc/sysconfig/network-scripts/rule-eth0.30
from 10.0.0.0/24 table vlan30
Siguiendo la misma filosofía, crearemos un nuevo fichero para la ruta:
[root@myServer]# vi /etc/sysconfig/network-scripts/route-eth0.30
default via 10.0.0.1 dev eth0.30 table vlan30
Con ésto conseguiremos que los cambios referentes a las rutas estáticas, no se pierdan tras reiniciar la red o la máquina, y ya tendríamos nuestra nueva red, con múltiples alias, lista para trabajar con tráfico VLAN tageado, manteniendo la red original del servidor.
Fuentes:
http://www.pukkapanel.com/guide6/add-vlan-and-ip-range
http://random.cconn.info/2013/01/14/centos-policy-routing-why-yes-it-can-be-done/
Foto por twicepix
Por cierto, asegúrate de contar con el paquete «vconfig» (puedes instalarlo con yum si no lo tienes) antes de aplicar los cambios, pues en caso contrario podrías encontrarte con el siguiente mensaje de error al reiniciar la red para aplicar los cambios:
«Bringing up interface eth0.30: Device eth0.30 does not seem to be present, delaying initialization.»
great!!! production activated