Passo a passo para criar um servidor VPN WireGuard em uma VM Debian/Ubuntu no Proxmox, com NAT, firewall e clientes Windows, macOS e celular.

Para que serve

Este guia monta um servidor VPN WireGuard em uma VM pequena dentro do seu Proxmox. Com ela, você e sua equipe acessam o painel do Proxmox, o SSH e as VMs por um túnel criptografado, sem deixar essas portas abertas para a internet. Cada notebook ou celular recebe um IP da rede da VPN e alcança a rede interna das VMs.

Por que em uma VM e não no host Proxmox

A recomendação da E-Consulters é manter a VPN em uma VM dedicada:

  • Superfície de ataque menor no hipervisor: o host fica só com o Proxmox; nenhum serviço extra escuta na internet a partir dele.
  • Isolamento: um erro de configuração ou uma falha na VPN fica restrita à VM, que você pode restaurar do backup ou recriar em minutos.
  • Atualizações independentes: você atualiza ou troca o sistema da VPN sem mexer no host.

Instalar o WireGuard direto no host funciona, mas não é recomendado pelos motivos acima.

Pré-requisitos

  • Proxmox VE 8.x ou 9.x com a bridge pública vmbr0 e a bridge interna vmbr1 (veja o artigo «Como configurar a rede do Proxmox para as VMs: bridge, bloco /28 IPv4 e IPv6»).
  • Um IP livre do seu bloco /28 para a VM da VPN.
  • Acesso ao console IPMI/iLO do servidor (rota de recuperação, veja o fim do artigo).
  • Endereços usados nos exemplos (todos fictícios, troque pelos seus):
    • Host Proxmox: 203.0.113.2 (vmbr0) e 10.10.10.1 (vmbr1). Gateway do bloco: 203.0.113.1.
    • VM da VPN: 203.0.113.5 (placa pública) e 10.10.10.2 (placa interna).
    • Rede da VPN: 10.8.0.0/24, servidor 10.8.0.1. Use uma faixa que não exista no escritório nem nas VMs.

Etapa 1: criar a VM da VPN

  1. Crie uma VM com Debian 12/13 ou Ubuntu 24.04: 1 a 2 vCPU, 1 GB de RAM e 8 a 10 GB de disco bastam.
  2. Placa 1 (net0) em vmbr0 e placa 2 (net1) em vmbr1, ambas VirtIO e com a opção Firewall marcada.
  3. Faça a VM iniciar primeiro no boot do host (exemplo com o ID 110): 
    qm set 110 --onboot 1 --startup order=1
  4. Configure a rede dentro da VM. No Debian, em /etc/network/interfaces (confira os nomes das placas com ip -br link): 
    auto ens18
iface ens18 inet static
    address 203.0.113.5/28
    gateway 203.0.113.1

auto ens19
iface ens19 inet static
    address 10.10.10.2/24
    A placa interna não leva gateway. No Ubuntu, faça o equivalente no netplan.

Etapa 2: instalar o WireGuard e gerar as chaves

  1. Instale as ferramentas (o módulo já vem no kernel): 
    apt update
apt install wireguard nftables qrencode
  2. Gere as chaves do servidor: 
    cd /etc/wireguard
umask 077
wg genkey | tee servidor.key | wg pubkey > servidor.pub
  3. Ative o encaminhamento de pacotes. No Debian 13 o /etc/sysctl.conf não existe mais por padrão, então use /etc/sysctl.d/: 
    echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-wireguard.conf
sysctl --system

Etapa 3: configurar o wg0 e as rotas até o Proxmox

Crie /etc/wireguard/wg0.conf:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = COLE_AQUI_O_CONTEUDO_DE_servidor.key
PostUp = nft add table ip wgnat; nft add chain ip wgnat post '{ type nat hook postrouting priority 100; }'; nft add rule ip wgnat post oifname "ens19" masquerade
PostDown = nft delete table ip wgnat

# Notebook do administrador
[Peer]
PublicKey = CHAVE_PUBLICA_DO_NOTEBOOK
AllowedIPs = 10.8.0.2/32

Por que o NAT: o host e as VMs têm como rota padrão a internet. Se um pacote chegasse com origem 10.8.0.2, a resposta sairia pela internet e se perderia. Com o NAT na placa interna, todo acesso vindo da VPN chega ao Proxmox e às VMs com origem 10.10.10.2, e a resposta volta pela VM da VPN. É a opção recomendada por funcionar sem mexer em nenhuma outra máquina.

Alternativa (rota estática): se você precisa ver nos logs o IP de cada usuário da VPN, remova as linhas PostUp/PostDown e ensine a rota de volta ao host e a cada VM que será acessada. No host, acrescente na seção vmbr1 de /etc/network/interfaces:

    up ip route add 10.8.0.0/24 via 10.10.10.2

Nas VMs Linux, use a mesma rota; no Windows, route -p add 10.8.0.0 mask 255.255.255.0 10.10.10.2. Nesse caso, nas regras de firewall use 10.8.0.0/24 como origem em vez de 10.10.10.2.

Suba a interface e ative no boot:

systemctl enable --now wg-quick@wg0
wg show

Etapa 4: firewall da VM da VPN

Na placa pública, a VM só precisa receber a porta 51820/udp. Em Datacenter > Firewall o firewall precisa estar ativo, e em VM 110 > Firewall você define a política. O arquivo /etc/pve/firewall/110.fw fica assim:

[OPTIONS]
enable: 1
policy_in: DROP

[RULES]
IN ACCEPT -i net0 -p udp -dport 51820
IN ACCEPT -i net1 -p tcp -dport 22

A segunda regra permite SSH na VM da VPN só pela rede interna; pela própria VPN o acesso chega por dentro do túnel e não passa por essa regra.

Atenção: com policy_in: DROP, o SSH pelo IP público da VM deixa de funcionar. Teste a VPN antes. Se perder o acesso à VM, use o console noVNC do Proxmox ou, se o painel também estiver inacessível, o IPMI/iLO (veja abaixo).

Etapa 5: criar os clientes da VPN

  1. Gere as chaves do dispositivo e cole a pública no [Peer] do wg0.conf: 
    wg genkey | tee notebook.key | wg pubkey > notebook.pub
  2. Monte o arquivo do cliente: 
    [Interface]
PrivateKey = CONTEUDO_DE_notebook.key
Address = 10.8.0.2/32

[Peer]
PublicKey = CONTEUDO_DE_servidor.pub
Endpoint = 203.0.113.5:51820
AllowedIPs = 10.8.0.0/24, 10.10.10.0/24
PersistentKeepalive = 25
    Só as redes em AllowedIPs passam pelo túnel; a internet do usuário continua saindo pela conexão dele.
  3. Aplique o novo peer sem derrubar os demais: wg syncconf wg0 <(wg-quick strip wg0)
  4. Importe no dispositivo: app oficial do WireGuard para Windows e macOS ("Import tunnel from file"); no Android/iOS, leia o QR code gerado com qrencode -t ansiutf8 < notebook.conf. Depois apague a chave do servidor: shred -u notebook.key.

Para revogar um dispositivo, apague o bloco [Peer] dele e rode novamente o wg syncconf.

Como saber se funcionou

  1. Na VM da VPN, wg show exibe o peer com latest handshake recente.
  2. No cliente: ping 10.8.0.1 e ping 10.10.10.1.
  3. O painel abre em https://10.10.10.1:8006. Para fechar o acesso pelo IP público, siga o artigo «Como liberar o acesso ao Proxmox (porta 8006), SSH e RDP só pela VPN».

Se a VM da VPN cair

O console IPMI/iLO do servidor continua acessível mesmo sem VPN. Por ele, faça login no host e rode qm status 110 e qm start 110. Se precisar do painel com urgência, pve-firewall stop libera temporariamente a porta 8006 pelo IP público; volte com pve-firewall start assim que terminar.

Problemas comuns

  • Sem handshake: porta 51820/udp bloqueada (regra da VM ou firewall do datacenter desativado), chave colada errada ou Endpoint incorreto.
  • Handshake ok, mas sem acesso ao Proxmox: falta ip_forward, a rede 10.10.10.0/24 não está no AllowedIPs do cliente ou o nome da placa no NAT (ens19) está errado.
  • "resolvconf: command not found": aparece quando o arquivo do cliente Linux tem DNS =. Remova a linha ou instale systemd-resolved.

Perguntas frequentes

Quantos recursos a VM do WireGuard precisa?

Para acesso administrativo, 1 vCPU e 1 GB de RAM sobram. Use 2 vCPU se muitos usuários transferirem arquivos grandes ao mesmo tempo.

Posso usar um container LXC em vez de VM?

Funciona, mas o container compartilha o kernel do host e precisa de permissões extras para criar a interface. A VM dá o isolamento que motivou tirar a VPN do host.

Preciso de um IP público só para a VPN?

Sim, é o mais simples: um dos IPs do seu /28 fica na placa pública da VM.

Precisa de ajuda?

Se o túnel não subir, abra um ticket com a saída de wg show (sem chaves privadas), o arquivo 110.fw e o ip -br addr da VM.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também