Modelos de configuração WireGuard prontos a usar 2026

Instalou o WireGuard no seu VPS. Leu três tutoriais contraditórios. O wg0.conf que colou não faz ping, ou faz ping mas há fugas de DNS, ou o kill switch desativa toda a sua máquina quando se desconecta. A causa é quase sempre a mesma: um modelo copiado sem compreender o contexto original.

Este guia fornece 8 modelos wg0.conf testados em produção a funcionar num Contabo VPS S, com caso de uso, armadilhas conhecidas e as quatro linhas que precisa adaptar. Escolha o que corresponde ao seu cenário, troque as chaves, conecte. Cinco minutos.

Por que usar modelos em vez de gerar tudo manualmente

O WireGuard é conhecido por ter uma configuração minimalista comparada ao OpenVPN, mas minimalista não significa trivial. Cada seção tem um significado implícito que os tutoriais copiam e colam sem explicar, e um único valor errado pode quebrar silenciosamente o túnel ou vazar tráfego sem nenhum sintoma visível imediato. Nos últimos seis meses, contamos mais de vinte tópicos no Reddit onde iniciantes faziam a mesma pergunta: "meu túnel está ativo, o ping funciona para o servidor, mas nenhuma conexão HTTP funciona a partir do cliente". Em 9 de cada 10 casos, era um AllowedIPs mal colocado ou um PostUp/PostDown ausente.

Os modelos abaixo cobrem 8 cenários de implantação distintos e reais. Cada um vem com um comentário de contexto descrevendo para quem é, o que garante e os limites conhecidos. Se o seu caso corresponder ao modelo em 80%, adapte os 20% restantes; se o seu caso não se encaixar em nenhum modelo, reconstrua a partir do modelo mais próximo e mantenha apenas as diretivas que se aplicam a si. Isso é mais rápido do que começar do zero e mais confiável do que remendar a partir de uma resposta aleatória do Stack Overflow de 2020.

A outra razão para usar modelos é a manutenção a longo prazo. Quando o WireGuard 1.1 for lançado (provavelmente entre 2026-2027) com alterações nas diretivas, republicaremos os modelos com os ajustes claramente marcados, e saberá exatamente qual linha atualizar no seu wg0.conf. É o equivalente a um manifesto Kubernetes versionado para VPN — o valor não está no conteúdo inicial, mas na capacidade de iterar de forma limpa em cima.

Convenções partilhadas

Cada modelo segue as mesmas regras — simplifique o seu modelo mental:

• Sub-rede do cliente: 10.66.66.0/24 (peers .2 → .254)
• Interface pública do servidor: eth0 (verifique com ip route | awk '/default/ {print $5}')
• Porta UDP: 51820 (alterável, veja o modelo 7 de ofuscação)
• Chaves: geradas via wg genkey | tee server.key | wg pubkey > server.pub
• Sysctl: net.ipv4.ip_forward=1 ativado no servidor (/etc/sysctl.conf)
• MTU: 1420 por padrão, ajustado quando necessário

Os blocos PrivateKey abaixo são espaços reservados — substitua pelos seus. Nunca comprometa estes ficheiros num repositório git público.

Modelo 1 — Servidor WireGuard padrão (1 cliente roadwarrior)

O caso mais comum: o seu VPS Contabo expõe um túnel para o seu MacBook na estrada.

# /etc/wireguard/wg0.conf (servidor)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook do Eric
PublicKey = CLIENT_PUBLIC_KEY_HERE
AllowedIPs = 10.66.66.2/32

Lado do cliente:

# /etc/wireguard/wg0.conf (cliente macOS/Linux)
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9, 149.112.112.112
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Pontos de atenção:

• AllowedIPs = 0.0.0.0/0, ::/0 roteia TODO o tráfego do cliente através do VPS — é isso que deseja para uma VPN clássica.
• PersistentKeepalive = 25 é obrigatório se o cliente estiver atrás de NAT (rede de hotel, 4G) — sem isso, o túnel morre após ~3 min de inatividade.
• DNS = 9.9.9.9 força a resolução Quad9 — caso contrário, o cliente usa DNS local e as suas consultas vazam.

Modelo 2 — VPN doméstica (túnel dividido: LAN local excluída)

Quer VPN para o seu tráfego web, mas manter o acesso à LAN local (impressora, NAS) sem passar pelo túnel.

# Cliente doméstico
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1420

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Tudo exceto LAN RFC1918 + multicast + APIPA
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/3, 224.0.0.0/4, 240.0.0.0/5, 248.0.0.0/6, 252.0.0.0/7, 254.0.0.0/8, 255.0.0.0/9
PersistentKeepalive = 25

O truque da sub-rede fragmentada (em vez de 0.0.0.0/0) faz com que o WireGuard adicione rotas específicas que não substituem a rota padrão. A sua LAN 192.168.x.x e 10.x.x.x permanecem acessíveis diretamente.

Ferramentas online para gerar esses intervalos: wg-allowed-ips.compute() ou Tunsafe / WireGuard Network Calc.

Modelo 3 — VPN de viagem com kill switch estrito de netfilter

Vai viajar para a China, Irão, Rússia. Se o túnel cair, nada vaza. Solução: kill switch de netfilter que bloqueia tudo exceto o tráfego via wg0 e o handshake do servidor.

# Cliente com kill-switch de viagem
[Interface]
PrivateKey = CLIENT_PRIVATE_KEY_HERE
Address = 10.66.66.2/24
DNS = 9.9.9.9
MTU = 1280

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PostUp = ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

Essas quatro linhas PostUp/PreDown são o verdadeiro kill switch — não um popup de aplicação. Até que wg-quick down wg0 seja executado, nenhum pacote sai da interface que não esteja marcado pelo WireGuard.

MTU 1280 para redes exigentes (hotéis, 3G). Perder 1% de throughput é melhor do que um túnel instável.

Modelo 4 — Multi-peer (5 dispositivos, mesmo utilizador)

Tem um MacBook, iPhone, iPad, VPS de trabalho, Raspberry Pi. Quer que todos sejam roteados pela mesma VPN com sub-redes separadas para monitorização.

# /etc/wireguard/wg0.conf (servidor)
[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# MacBook
PublicKey = MAC_PUBKEY
AllowedIPs = 10.66.66.2/32

[Peer]
# iPhone
PublicKey = IPHONE_PUBKEY
AllowedIPs = 10.66.66.3/32

[Peer]
# iPad
PublicKey = IPAD_PUBKEY
AllowedIPs = 10.66.66.4/32

[Peer]
# VPS de trabalho (Hetzner)
PublicKey = WORKER_PUBKEY
AllowedIPs = 10.66.66.5/32

[Peer]
# Raspberry Pi em casa
PublicKey = RPI_PUBKEY
AllowedIPs = 10.66.66.6/32

Cada peer tem um IP fixo na sub-rede 10.66.66.0/24. Se monitorizar via Prometheus (veja o guia de monitorização), pode etiquetar por IP e saber quem consome mais largura de banda.

Modelo 5 — Hub-and-spoke (peer-to-peer entre clientes)

Por padrão, o WireGuard não roteia entre peers. Se quiser que o seu iPhone fale com o seu Raspberry Pi através do servidor hub:

No servidor, adicione:

sysctl -w net.ipv4.ip_forward=1

E nos blocos [Peer] do servidor, defina AllowedIPs = 10.66.66.X/32 (IP único do peer).

Nos clientes, altere AllowedIPs:

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
# Toda a sub-rede, não apenas 0.0.0.0/0
AllowedIPs = 10.66.66.0/24

Agora, a partir do seu iPhone (10.66.66.3), pode ssh pi@10.66.66.6 diretamente — o hub encaminha.

Modelo 6 — Restrição de egress por peer (lista de permissões)

Caso avançado: um peer (o seu filho, um convidado, um serviço automatizado) deve conectar-se ao túnel mas apenas alcançar domínios/IPs específicos.

Adicione ao PostUp do servidor, além do MASQUERADE:

iptables -A FORWARD -s 10.66.66.50/32 -d 1.1.1.1 -j ACCEPT
iptables -A FORWARD -s 10.66.66.50/32 -d 142.250.0.0/15 -j ACCEPT  # Google
iptables -A FORWARD -s 10.66.66.50/32 -j REJECT

O peer 10.66.66.50 só pode alcançar 1.1.1.1 (DNS) e IPs do Google. Tudo o resto é rejeitado.

Modelo 7 — Ofuscação na porta 443 via udp2raw

Alguns firewalls corporativos bloqueiam UDP de saída. Solução: encapsular o WireGuard dentro de TCP/443 falso via udp2raw.

Lado do servidor:

udp2raw_amd64 -s -l 0.0.0.0:443 -r 127.0.0.1:51820 -k "p@ssw0rd_long" --raw-mode faketcp

Lado do cliente:

udp2raw_amd64 -c -l 127.0.0.1:50000 -r vpn.example.com:443 -k "p@ssw0rd_long" --raw-mode faketcp

No wg0.conf do cliente, altere Endpoint:

Endpoint = 127.0.0.1:50000

O throughput cai (~30% de overhead) mas passa por quase qualquer DPI corporativo.

Modelo 8 — Site-to-site (duas LANs interligadas)

Duas casas, dois gateways Raspberry Pi, um VPS Contabo como hub. Cada LAN vê a outra como se fosse local.

Servidor (hub VPS):

[Interface]
PrivateKey = HUB_PRIVATE_KEY_HERE
Address = 10.66.66.1/24
ListenPort = 51820

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Site A (LAN 192.168.10.0/24)
PublicKey = SITE_A_PUBKEY
AllowedIPs = 10.66.66.10/32, 192.168.10.0/24

[Peer]
# Site B (LAN 192.168.20.0/24)
PublicKey = SITE_B_PUBKEY
AllowedIPs = 10.66.66.20/32, 192.168.20.0/24

Site A (Raspberry Pi):

[Interface]
PrivateKey = SITE_A_PRIVATE_KEY_HERE
Address = 10.66.66.10/24

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = HUB_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Não se esqueça de ip_forward em ambas as Raspberries e de uma rota estática nas outras máquinas da LAN se precisarem responder do outro site.

Diagnóstico rápido quando nada funciona

Colou o modelo, executou wg-quick up wg0, ele inicia — mas o ping falha. Lista de verificação nesta ordem:

• wg show: último handshake recente? Se "nunca" → handshake KO, verifique Endpoint, porta UDP no firewall do servidor (ufw status ou iptables -L).
• ip route no cliente: rota para a sub-rede VPN presente? Se não → AllowedIPs do cliente está errado.
• dig @9.9.9.9 ifconfig.me +short do cliente conectado: retorna o IP do VPS? Se não → MASQUERADE ausente no servidor, ou ip_forward = 0.
• tcpdump -i wg0 no servidor: vê pacotes a chegar? Se sim, mas nada sai de eth0 → regra FORWARD/MASQUERADE ausente.
• MTU: ping -M do -s 1400 1.1.1.1 do cliente. Se "Frag needed" → reduza MTU no wg0.conf para 1380 ou 1280.

Se está a começar do zero e está preso, o guia de configuração passo a passo do Contabo percorre toda a instalação desde o SSH inicial.

Em produção: o que estes modelos omitem

São intencionalmente minimalistas. Para produção a longo prazo, planeie:

• Backup regular de /etc/wireguard/ (perder a chave do servidor = regenerar todos os clientes)
• Rotação de chaves a cada 12-18 meses (procedimento: gerar nova chave, adicionar peer paralelo, migrar clientes um a um, retirar peer antigo)
• Monitorização via Prometheus + wireguard_exporter (veja guia de monitorização)
• Fail2ban na porta UDP 51820 se detectar tentativas de scan de porta em journalctl -u wg-quick@wg0
• Limite de largura de banda por peer via tc (controlo de tráfego Linux) se um peer consumir toda a largura de banda

E acima de tudo: nunca comprometa um wg0.conf real num repositório, mesmo privado. Mantenha-os .gitignore'd ou encripte com age / sops.

Quando o WireGuard não é suficiente: V2Ray para países censurados

O WireGuard é excelente para casos de uso de privacidade padrão. No entanto, o WireGuard vanilla (incluindo NordLynx) é agora sistematicamente bloqueado pelo Grande Firewall da China e cada vez mais filtrado na Rússia e no Irão — o ML-DPI do GFW identifica sessões WireGuard em minutos.

Se o seu objetivo é contornar a censura ativa (China, Irão, Rússia), os modelos WireGuard não ajudarão por si só. Precisa de ofuscação: ou WireGuard + Cloak (camada de mascaramento TLS) ou uma mudança completa de protocolo para V2Ray VMess/VLESS com REALITY para China, Irão, Rússia. O protocolo REALITY do V2Ray torna o seu servidor indistinguível de um nó CDN da Microsoft — o estado da arte atual contra a inspeção profunda de pacotes do GFW em 2026.

Indo mais fundo

Se quiser entender por que o WireGuard supera o OpenVPN com CPU igual, fizemos uma comparação técnica detalhada com benchmarks reais de iperf3 no Contabo, módulo de kernel vs espaço de utilizador, e perfil de bateria do iPhone.

E para a parte de prevenção de fugas, o guia de kill switch para Linux (iptables + systemd) mostra como garantir zero fuga mesmo quando o WireGuard falha.

Prefere um assistente visual em vez de blocos INI brutos? O nosso gerador de configuração WireGuard pega no IP do seu servidor, sub-rede e contagem de peers e gera um wg0.conf pronto a colar em menos de um minuto. E para verificar se o Contabo VPS S é mais barato do que o seu plano NordVPN atual ao longo de 2 anos, insira os números no nosso calculador de custos de VPN auto-hospedada.

Cada modelo acima é construído para funcionar num Contabo VPS S a 4,99 €/mês (/go/contabo-vps-2y) — espaço suficiente para um túnel de produção estável além de outros serviços auto-hospedados ao lado.