Escrito por coder el 14 de mayo de 2008
Sí amigos, es posible y, al menos en Gentoo (¿quién dijo que abandonaría Gentoo? ;_)) se puede llevar a cabo sin apenas guarrear con scripts adicionales. Es más, desde mi punto de vista no he cometido ninguna guarrada.
Bien, supongamos que, al igual que yo, estáis majaras y adquirís un PC para casa tipo el Dell Optiplex 755 que yo me compré en noviembre. Al ser un Core 2 Duo con VT-d gracias a la magia de Intel y su placa ICH9, podemos virtualizar como Zeus manda. A ese PC le añadí dos ethernets adicionales para poder crear el invento este y que funcionara bien. Muchos de los miles de lectores que por aquí se pasan estarán pensando 'oye McFly, hasta donde yo sé, no hace falta tener tarjetas adicionales para que el SO virtualizado pueda tener red'. Cierto, basta con crear un bridge al que añadirle el interfaz del host en modo promiscuo y ya lo tendremos. Es lo que se hace con VMware y también con KVM, pero el quiz de la cuestión es: ¿cómo hacer lo mismo pero teniendo los SOs virtualizados aislados? Los avispados ya sabrán la respuesta: usando las VLANs que trae KVM. Cierto... pero no es suficiente. Quizá con el esquema siguiente se vea mejor. Abróchense los cinturones para una dosis de ASCII:
__________________________________________
| HOST (Gentoo) |
| |
| eth0 | eth1 | eth2 |
|10.12.34.250 | no IP | no IP |
--------------------------------------------
| | guest1 | guest2 |
| | netbsd4 | w2k8 |
| | 192.168.34.2 | 172.29.19.1 |
| -----------------------------
| | |
| | |
----------- --------- -----------
| SWITCH 1 | |SWITCH 2 | | SWITCH 3 |
----------- --------- -----------
(network 1) (network 2) (network 3)
Así podemos tener una DMZ de dos niveles _real_, aislando al host de sus dos guests, sin el truquito de las VLANs y, lo que es más importante, dotando a cada guest de su propia ethernet para que pueda aprovecharla sin compartirla. Obviamente, si no tenemos más equipos (es decir, si estamos trasteando en casa o en nuestro laboratorio en la ofi) no tenemos por qué tener ningún switch, por lo que la gestión de las subredes y sus firewalls podremos hacerla con ebtables e iptables.
Bueno, y ahora el regalito: la config. Por un lado, en /etc/conf.d/net creamos los bridges y los taps (recuerden que KVM funciona con taps), y asignamos cada una de las dos ethernets a los bridges:
config_eth0=( "10.12.34.250/24" )
routes_eth0=( "default via 10.12.34.234" )
config_eth1=( "null" )
config_eth2=( "null" )
tuntap_tap0="tun"
tuntap_tap1="tun"
config_tap0=( "null" )
config_tap1=( "null" )
bridge_br0="eth1"
config_br0=( "null" )
brctl_br0=( "stp on" )
bridge_br1="eth2"
config_br1=( "null" )
brctl_br1=( "stp on" )
Comprobamos que cada cosa está en su sitio:
probeta ~ # brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0001021929ec yes eth1
br1 8000.0048548867f6 yes eth2
probeta ~ #
Bien, lo están. Ahora la key está en que en el momento de levantar una máquina virtual le especificaremos a KVM el script para levantar el interfaz. Pongo un ejemplo de una imagen de Windows 2008 asignando el tap0 al bridge0:
# kvm -hda w2k8-i686.img -bootc -m 1024 -smp 2 -vnc :1 -k es-usbdevice tablet -net nic,vlan=0,type=rtl8139 -net tap,vlan=0,ifname=tap0,script=/etc/kvm/qemu-ifup-tap0
Y este es el script /etc/kvm/qemu-ifup-tap0:
probeta ~ # cat /etc/kvm/qemu-ifup-tap0
#!/bin/bash
ifconfig $1 up
brctl addif br0 $1
probeta ~ #
Y con eso ya lo tenemos en su bridge:
probeta ~ # brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0001021929ec yes eth1
tap0
br1 8000.0048548867f6 yes eth2
probeta ~ #
Ahí está, ya se ha asignado al bridge que toca.
No os quejaréis, ¡os lo doy todo hecho!
« Ejecutar Xorg como usuario no privilegiado
VCF: Desmantelar o morir »