Cristian Vicente

En una entrada anterior comenté la sustitución de Proxmox por Virtual Machine Manager y me quedó por indicar cómo administrar desde él el servicio LXC de forma remota. Y es que no permite la creación del sistema de ficheros raíz de nuestro nuevo contenedor de forma remota, por lo que hay que proveerle la ruta en la que se encuentra. Al final opté por una solución relativamente sencilla: instalar lxc pero no habilitarlo, simplemente usarlo para descargar nuestros sistemas de ficheros raíz:

apt install lxc
lxc-create -n ubuntu1804 -t download

Nos mostrará un listado y, en mi caso, seleccioné descargar una Ubuntu Bionic para arquitectura AMD64. Después, simplemente hice una copia para utilizarla para un servidor Seafile, dejando la descargada para usarla como plantilla cada vez que necesitase un nuevo contenedor:

cp -a /var/lib/lxc/ubuntu1804/rootfs/* /lxc/001-seafile/

El problema es que lo que hemos descargado es un sistema Ubuntu cuyo usuario root no tiene contraseña. Para resolverlo deberemos cargar el sistema y asignarle una contraseña:

chroot /lxc/001-seafile/

passwd

exit

Ahora sencillamente podríamos desinstalar el paquete «lxc» y simplemente utilizar nuestra plantilla.

Instalar un cliente VPN en un contenedor de Proxmox (LXC) no debería ser un gran problema, simplemente realizar un «apt install openvpn», configurar la conexión con el servidor VPN y ya está. Pero no, existen problemas con la interfaz de red TUN/TAP a la que intenta tener acceso OpenVPN debido a que no existe:

ERROR: Cannot open TUN/TAP dev /dev/net/tun

Para solucionarlo hay que ir al fichero de configuración del contenedor («/etc/pve/lxc/XXX.conf») y añadir las siguientes líneas:

lxc.cgroup.devices.allow: c 10:200 rwm
lxc.hook.autodev: sh -c «modprobe tun; cd ${LXC_ROOTFS_MOUNT}/dev; mkdir net; mknod net/tun c 10 200; chmod 0666 net/tun»

Esto nos permitirá poder hacer uso de OpenVPN desde que la máquina arranca, ya que generar la estructura en un script de «init.d» o «crontab», a pesar de que funciona si iniciamos a mano OpenVPN, no lo hará de forma no asistida.

A pesar de todo lo anterior, veremos que perdemos cierta conectividad con la máquina y el log del sistema («/var/log/syslog») se nos llenará de mensajes del siguiente tipo:

Dec 21 07:12:11 gateway kernel: martian source 98.187.15.124 from 98.187.15.97, on dev br1

Dec 21 07:12:11 gateway kernel: ll header: ff:ff:ff:ff:ff:ff:00:14:f1:e8:69:db:08:06

Quizás por una mala configuración de interfaces de red por mi parte, pero habiendo sólo una con su IP fija no creo que debiese ser problemático. Al final opté por crear una máquina virtual en vez de un contenedor con una Debian 10 y todo ha ido prácticamente a la primera (salvo lo de montar una unidad NFS al arranque, que necesita de una IP asignada de manera estática, pero eso ya es otro cuento).

Como nota final, cabe tener en cuenta que, para ahorrar consumo de CPU (hasta un 20% de ahorro con un núcleo), existe la necesidad de habilitar las instrucciones extendidas AES del procesador (si las tuviese). Para ello debemos configurar la máquina virtual con un tipo de CPU host y máquina Q35. Para comprobar que la CPU tiene dichas instrucciones sólo hay que lanzar el comando «cpuid | grep -i aes | sort | uniq» que nos devolverá algo como esto:

AES instruction = true
VAES instructions = false

Y comprobar que se carga el módulo correspondiente con el comando «sort -u /proc/crypto | grep module» que debería darnos algo tal que así:

module : aesni_intel
module : aes_x86_64
module : crc32c_generic
module : crc32c_intel
module : crc32_pclmul
module : crct10dif_pclmul
module : cryptd
module : ghash_clmulni_intel
module : kernel