WireGuard en LXC o en una VM sobre Proxmox: ¿dónde debería ejecutarse?

WireGuard necesita exactamente un núcleo que sea dueño de su interfaz, y ese hecho resuelve la mayor parte del debate sobre la ubicación en Proxmox antes de que el rendimiento entre en la sala. Un contenedor LXC es una vista de espacio de nombres del núcleo del host, mientras que una VM arranca el suyo. Así que la pregunta útil no es qué opción es más ligera, sino qué núcleo está dispuesto a modificar y con qué ruta de recuperación puede vivir. Responda eso y la elección entre host, contenedor o VM suele hacerse sola.

Un invitado LXC trabaja dentro del núcleo del host

Instalar wireguard-tools dentro de un contenedor le da el programa de control, no un núcleo privado. La interfaz wg0 que crea se registra en la pila de red del host y aparece en su lista de módulos. Por eso un contenedor puede pasar todas las comprobaciones de paquetes y aun así fallar en el primer comando wg cuando al núcleo del host le falta el módulo. Y la referencia de contenedores de Proxmox documenta ese modelo de núcleo compartido junto con los límites de espacio de nombres y de privilegios dentro de los que trabaja.

La autoridad es la segunda restricción. Levantar una interfaz y adjuntarle direcciones requiere derechos de administración de red dentro del espacio de nombres que la posee, y un contenedor sin privilegios mapea esos derechos a través de su espacio de nombres de usuario en lugar de tenerlos directamente. Nunca recurra al privilegio total como primera respuesta; mire qué se le pide realmente al contenedor y luego concédalo.

El núcleo del host también es una dependencia compartida. Una actualización del núcleo de Proxmox cambia la implementación de WireGuard bajo cada contenedor a la vez, lo cual es cómodo hasta que una actualización y las expectativas de un contenedor no coinciden.

Host, contenedor, VM: qué posee realmente cada ubicación

La ubicación en el host pone la VPN en la propia red del hipervisor. Las rutas, las reglas de cortafuegos y el túnel pasan a formar parte de la recuperación del host, y un error allí puede llevarse la interfaz de gestión. Eso es aceptable para el enrutamiento de infraestructura en un host al que llega por consola, y doloroso en una máquina remota sin acceso fuera de banda.

Un contenedor mantiene el servicio empaquetado y reiniciable mientras sigue tomando prestado el núcleo del host. Encaja en un servicio deliberadamente de núcleo compartido y le da una unidad pequeña que reconstruir. No le da un núcleo independiente, así que todo lo que necesite una compilación de módulo concreta apunta lejos de esta opción.

Una VM cuesta más memoria y otro sistema que parchear, y a cambio el túnel obtiene su propio núcleo, su propia tabla de enrutamiento y un límite de instantánea. Cuando la VPN es lo que se revierte tras un cambio malo, esa instantánea vale la sobrecarga.

Tres condiciones que eligen por usted

Si el túnel necesita una versión de núcleo o una función de WireGuard que el host de Proxmox no incluye, deténgase aquí y use una VM. No puede instalar un núcleo más nuevo en un contenedor, y no debería reemplazar el núcleo del hipervisor para satisfacer a un solo invitado.

Si el túnel es la puerta de enlace del sitio para prefijos LAN reales, pregunte quién es dueño ya de la ruta de retorno. Un contenedor puede enrutar tráfico, pero sus interfaces se sientan en la pila del host, así que el host acaba cargando parte de la configuración, lo haya planificado o no. La ubicación en el host es honesta al respecto; la ubicación en contenedor a menudo no lo es.

Luego sopesen el radio de impacto de un error. Reiniciar un contenedor es barato, restaurar una instantánea de VM es predecible y reparar la red del host puede requerir acceso físico o por consola. La elección correcta es aquella cuyo peor caso puede recuperar de verdad en la hora en que ocurre.

Una cuarta pregunta rara vez es decisiva pero merece decirse: ¿algo más en el host necesita ver la interfaz del túnel? Si es así, la ubicación en el host o en contenedor mantiene esa visibilidad local, mientras que una VM le obliga a enrutar entre el invitado y el host.

Demuestre la ubicación antes de enrutar tráfico por ella

Una vez instalado, confirme qué núcleo sirve realmente la interfaz y si al contenedor se le concedió autoridad suficiente para mantenerla:

$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
  listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0

Después revise el lado del reenvío desde el host, porque un apretón de manos por sí solo demuestra únicamente que el túnel está levantado. Use ip route get para una dirección de cliente y confirme que el siguiente salto y la interfaz coinciden con el diseño, y que la ruta de retorno existe en el lado remoto.

Deje el despliegue con un propietario escrito: qué núcleo lleva la implementación, qué espacio de nombres sostiene la interfaz y qué prefijos puede reenviar la puerta de enlace. Esa frase evita más incidentes que cualquier comparación de referencia de las tres ubicaciones.