WireGuard nun LXC ou nunha VM sobre Proxmox: onde debería correr?

WireGuard necesita exactamente un núcleo que sexa dono da súa interface, e ese feito resolve a maior parte do debate sobre a localización en Proxmox antes de que o rendemento entre na sala. Un contedor LXC é unha vista de espazo de nomes do núcleo do host, mentres que unha VM arrinca o seu. Así que a pregunta útil non é que opción é máis lixeira, senón que núcleo está disposto a modificar e con que ruta de recuperación pode vivir. Responda iso e a elección entre host, contedor ou VM adoita facerse soa.

Un convidado LXC traballa dentro do núcleo do host

Instalar wireguard-tools dentro dun contedor dálle o programa de control, non un núcleo privado. A interface wg0 que crea rexístrase na pila de rede do host e aparece na súa lista de módulos. Por iso un contedor pode pasar todas as comprobacións de paquetes e aínda así fallar no primeiro comando wg cando ao núcleo do host lle falta o módulo. E a referencia de contedores de Proxmox documenta ese modelo de núcleo compartido xunto cos límites de espazo de nomes e de privilexios dentro dos que traballa.

A autoridade é a segunda restrición. Levantar unha interface e engadirlle enderezos require dereitos de administración de rede dentro do espazo de nomes que a posúe, e un contedor sen privilexios mapea eses dereitos a través do seu espazo de nomes de usuario en lugar de telos directamente. Nunca recorra ao privilexio total como primeira resposta; mire que se lle pide realmente ao contedor e logo concédaoo.

O núcleo do host tamén é unha dependencia compartida. Unha actualización do núcleo de Proxmox cambia a implementación de WireGuard baixo cada contedor á vez, o que é cómodo ata que unha actualización e as expectativas dun contedor non coinciden.

Host, contedor, VM: que posúe realmente cada localización

A localización no host pon a VPN na propia rede do hipervisor. As rutas, as regras de cortafuegos e o túnel pasan a formar parte da recuperación do host, e un erro alí pode levar a interface de xestión. Iso é aceptable para o encamiñamento de infraestrutura nun host ao que chega por consola, e doloroso nunha máquina remota sen acceso fóra de banda.

Un contedor mantén o servizo empaquetado e reiniciable mentres segue tomando prestado o núcleo do host. Encádrase nun servizo deliberadamente de núcleo compartido e dálle unha unidade pequena que reconstruír. Non lle dá un núcleo independente, así que todo o que necesite unha compilación de módulo concreta apunta lonxe desta opción.

Unha VM custa máis memoria e outro sistema que parchear, e a cambio o túnel obtén o seu propio núcleo, a súa propia táboa de encamiñamento e un límite de instantánea. Cando a VPN é o que se reverte tras un cambio malo, esa instantánea vale a sobrecarga.

Tres condicións que elixen por vostede

Se o túnel necesita unha versión de núcleo ou unha función de WireGuard que o host de Proxmox non fornece, detéñase aquí e use unha VM. Non pode instalar un núcleo máis novo nun contedor, e non debería substituír o núcleo do hipervisor para satisfacer un só convidado.

Se o túnel é a porta de enlace do sitio para prefixos LAN reais, pregunte quen é xa dono da ruta de volta. Un contedor pode encamiñar tráfico, pero as súas interfaces están na pila do host, así que o host acaba cargando parte da configuración, planificáse ou non. A localización no host é honesta niso; a localización en contedor a miúdo non.

Despois pese o raio de impacto dun erro. Reiniciar un contedor é barato, restaurar unha instantánea de VM é predíbel e reparar a rede do host pode requirir acceso físico ou por consola. A elección correcta é aquela cuxo peor caso pode recuperar de verdade na hora en que ocorre.

Unha cuarta pregunta raramente é decisiva pero merece dicirse: algo máis no host necesita ver a interface do túnel? Se si, a localización no host ou en contedor mantén esa visibilidade local, mentres que unha VM obriga a encamiñar entre o convidado e o host.

Demostre a localización antes de encamiñar tráfico por ela

Unha vez instalado, confirme que núcleo serve realmente a interface e se ao contedor se lle concedeu autoridade suficiente para mantela:

$ 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

Despois revise o lado do reenvío desde o host, porque un aperto de mans por si só demostra unicamente que o túnel está levantado. Use ip route get para un enderezo de cliente e confirme que o seguinte salto e a interface coinciden co deseño, e que a ruta de volta existe no lado remoto.

Deixe o despregamento cun propietario escrito: que núcleo leva a implementación, que espazo de nomes sostén a interface e que prefixos pode reenviar a porta de enlace. Esa frase evita máis incidentes que calquera comparación de referencia das tres localizacións.