WireGuard em LXC ou numa VM no Proxmox: onde deve correr?

O WireGuard precisa de exatamente um kernel para ser dono da sua interface, e esse facto resolve a maior parte do debate sobre a colocação no Proxmox antes de o desempenho entrar na conversa. Um contentor LXC é uma vista de espaço de nomes do kernel do host, enquanto uma VM arranca o seu próprio. A pergunta útil não é, portanto, qual opção é mais leve, mas qual kernel está disposto a alterar e com que caminho de recuperação consegue viver. Responda a isso e a escolha entre host, contentor ou VM costuma fazer-se sozinha.

Um convidado LXC trabalha dentro do kernel do host

Instalar wireguard-tools dentro de um contentor dá-lhe o programa de controlo, não um kernel privado. A interface wg0 que cria é registada na pilha de rede do host e aparece na sua lista de módulos. É por isso que um contentor pode passar todas as verificações de pacotes e mesmo assim falhar no primeiro comando wg quando falta o módulo ao kernel do host. E a referência de contentores do Proxmox documenta esse modelo de kernel partilhado, juntamente com os limites de espaço de nomes e de privilégios em que trabalha.

A autoridade é a segunda restrição. Levantar uma interface e associar-lhe endereços exige direitos de administração de rede dentro do espaço de nomes que a possui, e um contentor sem privilégios mapeia esses direitos através do seu espaço de nomes de utilizador em vez de os deter diretamente. Nunca recorra ao privilégio total como primeira resposta; veja o que é realmente pedido ao contentor e conceda isso.

O kernel do host é também uma dependência partilhada. Uma atualização do kernel do Proxmox altera a implementação do WireGuard sob cada contentor de uma vez, o que é conveniente até uma atualização e as expectativas de um contentor não concordarem.

Host, contentor, VM: o que cada colocação realmente possui

A colocação no host põe a VPN na rede própria do hipervisor. As rotas, as regras de firewall e o túnel passam a fazer parte da recuperação do host, e um erro aí pode levar consigo a interface de gestão. Isso é aceitável para o encaminhamento de infraestrutura num host a que chega por consola, e doloroso numa máquina remota sem acesso fora de banda.

Um contentor mantém o serviço empacotado e reiniciável enquanto continua a pedir emprestado o kernel do host. Adequa-se a um serviço deliberadamente de kernel partilhado e dá-lhe uma unidade pequena para reconstruir. Não lhe dá um kernel independente, por isso tudo o que exija uma compilação de módulo específica aponta para longe desta opção.

Uma VM custa mais memória e outro sistema para corrigir, e em troca o túnel obtém o seu próprio kernel, a sua própria tabela de encaminhamento e um limite de instantâneo. Quando a VPN é o que se reverte após uma alteração má, esse instantâneo vale a sobrecarga.

Três condições que escolhem por si

Se o túnel precisar de uma versão de kernel ou de uma funcionalidade do WireGuard que o host Proxmox não fornece, pare aqui e use uma VM. Não pode instalar um kernel mais recente num contentor, e não deve substituir o kernel do hipervisor para satisfazer um único convidado.

Se o túnel for a porta de entrada do site para prefixos LAN reais, pergunte quem já é dono da rota de retorno. Um contentor pode encaminhar tráfego, mas as suas interfaces ficam na pilha do host, pelo que o host acaba por transportar parte da configuração, quer tenha planeado isso ou não. A colocação no host é honesta quanto a isto; a colocação em contentor muitas vezes não é.

Depois avalie o raio de impacto de um erro. Reiniciar um contentor é barato, restaurar um instantâneo de VM é previsível, e reparar a rede do host pode exigir acesso físico ou por consola. A escolha certa é aquela cujo pior caso consegue realmente recuperar na hora em que acontece.

Uma quarta pergunta raramente é decisiva mas vale a pena dizer: algo mais no host precisa de ver a interface do túnel? Se sim, a colocação no host ou em contentor mantém essa visibilidade local, enquanto uma VM o obriga a encaminhar entre o convidado e o host.

Prove a colocação antes de encaminhar tráfego por ela

Depois de instalado, confirme que kernel está realmente a servir a interface e se o contentor recebeu autoridade suficiente para a manter:

$ 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

Depois verifique o lado do reencaminhamento a partir do host, porque um aperto de mão sozinho só prova que o túnel está levantado. Use ip route get para um endereço de cliente e confirme que o salto seguinte e a interface correspondem ao desenho, e que o caminho de retorno existe do outro lado.

Deixe a implementação com um proprietário escrito: que kernel transporta a implementação, que espaço de nomes detém a interface e que prefixos a porta de entrada pode reencaminhar. Essa frase evita mais incidentes do que qualquer comparação de referência das três colocações.