Problemas al utilizar iptables/NAT en las VMs

[naionabus]

Probé ejecutar el laboratorio de NAT que está en la página oficial de netkit y no funciona (arrancan todas las VMs pero la que tiene que hacer NAT queda colgada.

Pensando que era problema del lab intenté crear un laboratorio que utilice iptables para poder probar NAT y pasa lo mismo, al ejecutar el comando iptables la VM se congela y no permite ni el halt

Luego probé instalando el core/kernel/fs oficiales desde la pagina del netkit y tanto el lab oficial de NAT como mi lab funcionan bien.

[maurom]

Efectivamente.
Este bug existe desde los inicios y, si bien lo habíamos advertido tiempo atrás, nunca pudimos darle la dedicación que merece.

Es 100% reproducible ejecutando el comando siguiente dentro de un host virtual de netkit:

root@client:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

(vm hang)

Por las pruebas que ejecuté, pude reducirlo al módulo de tracking de conexiones de netfilter: nf_conntrack.

Por algún motivo que desconozco, el módulo nf_conntrack.ko de nuestra distribución (versión de kernel 3.2.86) cuelga la máquina virtual al cargarse.

root@client:~# strace modprobe nf_conntrack
...
open("/lib/modules/3.2.86-netkit-ng-K3.2/kernel/net/netfilter/nf_conntrack.ko", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=75656, ...}) = 0
mmap2(NULL, 75656, PROT_READ, MAP_PRIVATE, 3, 0) = 0x402d0000
init_module(0x402d0000, 75656, ""

(vm hang)

Mientras que el módulo nf_conntrack.ko provisto por la instalación estándar de netkit-ng (versión de kernel 3.2.54) funciona correctamente, como puede verse luego de ejecutar la siguiente prueba y workaround:

Prueba / Workaround

Ejecutar, en el host real (y por única vez) los siguientes comandos:

NETFILTER=~/netkit/netkit-ng/kernel/modules/lib/uml/modules/3.2.86-netkit-ng-K3.2/kernel/net/netfilter/

mv $NETFILTER/nf_conntrack.ko $NETFILTER/nf_conntrack.ko.broken
cd ~/netkit/bundles
wget -c https://github.com/netkit-ng/netkit-ng-build/releases/download/0.1.3/netkit-ng-kernel-i386-K3.2-0.1.3.tar.bz2
tar xvf netkit-ng-kernel-i386-K3.2-0.1.3.tar.bz2 \
    --strip-components 10 netkit-ng/kernel/modules/lib/uml/modules/3.2.54-netkit-ng-K3.2/kernel/net/netfilter/nf_conntrack.ko
sed -i 's/3.2.54-netkit/3.2.86-netkit/' nf_conntrack.ko
cp nf_conntrack.ko $NETFILTER
cd ..

Esto reemplaza el módulo que falla por el original de netkit-ng, que funciona.

Luego es posible utilizar iptables en cualquier máquina de netkit que antes se colgaba, por ejemplo en cualquier host del laboratorio webserver.

En el host:

cd ~/netkit/netkit-lab_webserver
lstart

En la máquina virtual client o server:

root@client:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
root@client:~# iptables -t nat -L POSTROUTING
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  anywhere             anywhere
root@client:~#

Dejo el bug en suspenso mientras me quedo pensando la mejor forma de (re)distribuir este módulo en nuestra instalación.

Hasta tanto esté resuelto, el workaround indicado funciona para salir del paso.