WireGuard

1. Contexto histórico e normativo

O WireGuard foi criado por Jason A. Donenfeld e apresentado em 2016 como uma alternativa radicalmente mais simples e segura aos protocolos VPN tradicionais. Sua premissa central é de que menos código é mais segurança: enquanto o OpenVPN possui dezenas de milhares de linhas, o WireGuard tem aproximadamente 4.000 linhas no kernel, o que facilita auditoria formal e reduz drasticamente a superfície de ataque.

O protocolo foi formalmente integrado ao kernel Linux 5.6 (2020), e desde então foi portado para outros sistemas operacionais (Windows, macOS, FreeBSD, Android, iOS) e incorporado por grandes players como Cloudflare (WARP) e Mikrotik (RouterOS v7). Em 2021, Donenfeld recebeu o prêmio Pwnie Award de melhor criptografia aplicada.

Diferente de protocolos que negociam algoritmos de criptografia (como TLS no OpenVPN), o WireGuard fixa um único conjunto de primitivas modernas: Curve25519 (troca de chaves), ChaCha20-Poly1305 (cifra autenticada) e BLAKE2s (hash). Essa decisão elimina uma classe inteira de vulnerabilidades relacionadas a downgrade e negociação de algoritmos fracos.

2. Arquitetura interna

O WireGuard opera em espaço de kernel (no Linux), eliminando a troca de contexto entre kernel e userspace que penaliza VPNs baseadas em userspace (como OpenVPN tradicional). Isso resulta em maior throughput e menor latência.

• Interface de rede virtual — cada túnel WireGuard aparece como uma interface (ex.: wg0), podendo ser gerenciada com ferramentas padrão de rede (ip, ifconfig, firewalls).
• Handshake de 1 round-trip — a conexão estabelece quase instantaneamente, sem múltiplas trocas.
• Somente UDP — não há modo TCP; o WireGuard trata perda de pacotes de forma simples, sem retransmissão.
• Roaming automático — o endpoint de um peer pode mudar de IP, e o WireGuard se adapta automaticamente.
• Silêncio por design — o WireGuard não responde a pacotes não autenticados, o que dificulta escaneamento e fingerprinting, mas também complica o troubleshooting (seção 14).

3. Instalação

# Debian/Ubuntu — kernel já inclui WireGuard desde 5.6
apt update
apt install wireguard wireguard-tools

O pacote wireguard-tools inclui os utilitários wg e wg-quick para gerenciamento.

4. Geração de chaves

# No servidor
umask 077
wg genkey | tee server-private.key | wg pubkey > server-public.key

# No cliente (um par por peer)
wg genkey | tee client-private.key | wg pubkey > client-public.key

WireGuard não usa PKI/certificados — cada peer tem apenas um par de chaves simples (Curve25519). Para remover acesso, basta remover a chave pública do peer no servidor; não há CRL ou revogação formal.

5. Configuração de servidor e peer

# /etc/wireguard/wg0.conf — SERVIDOR
[Interface]
PrivateKey = <conteúdo de server-private.key>
Address = 10.100.0.1/24
ListenPort = 51820
MTU = 1420

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

[Peer]
PublicKey = <conteúdo de client-public.key>
AllowedIPs = 10.100.0.2/32

# /etc/wireguard/wg0.conf — CLIENTE (ex.: técnico de NOC)
[Interface]
PrivateKey = <conteúdo de client-private.key>
Address = 10.100.0.2/32
DNS = 10.0.0.5

[Peer]
PublicKey = <conteúdo de server-public.key>
Endpoint = vpn.exemplo-isp.com.br:51820
AllowedIPs = 10.0.0.0/16   # apenas redes internas do ISP
PersistentKeepalive = 25   # mantém NAT/firewall aberto, útil com CGNAT

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

6. AllowedIPs — o conceito mais mal-entendido

AllowedIPs tem dupla função:

• No servidor — define quais IPs de origem são aceitos daquele peer (roteamento de entrada).
• No cliente — define quais destinos devem ser roteados através do túnel (roteamento de saída).

0.0.0.0/0 no cliente envia todo o tráfego pela VPN (full tunnel). Para acesso administrativo de NOC, normalmente você quer apenas a faixa interna do ISP (10.0.0.0/16), não a navegação geral do técnico.

7. Integração com Mikrotik RouterOS

O RouterOS v7+ tem suporte nativo a WireGuard:

/interface wireguard add name=wg0 listen-port=51820
/ip address add address=10.100.0.1/24 interface=wg0

/interface wireguard peers add interface=wg0 \
    public-key="chave-publica-do-cliente" \
    allowed-address=10.100.0.2/32

Cenário comum: PoP remoto com Mikrotik na borda, conectado via WireGuard ao NOC central — mais simples e leve que IPsec ou GRE para gerência.

8. WireGuard atrás de CGNAT

Se o cliente WireGuard está atrás de CGNAT, PersistentKeepalive (seção 5) é essencial — sem ele, a tradução de porta no CGNAT expira por inatividade, e o servidor perde a capacidade de iniciar handshake até o cliente enviar tráfego novamente. Valor de 25 segundos é um bom ponto de partida, ajustável conforme o timeout real do CGNAT.

9. Verificação — comando wg

wg show

# Saída mostra, por peer: endpoint, allowed ips, latest handshake,
# transfer (bytes rx/tx). "latest handshake" antigo (ou nunca)
# é o primeiro sinal de problema de conectividade.

10. Monitoramento e métricas

O WireGuard não possui daemon próprio — o estado é consultado diretamente via wg. Script de health check para Zabbix/PRTG:

#!/bin/bash
# check_wireguard.sh — verifica se o túnel está ativo e handshake recente
INTERFACE="wg0"
ULTIMO_HANDSHAKE=$(wg show $INTERFACE latest-handshakes 2>/dev/null | awk '{print $2}')
if [ -z "$ULTIMO_HANDSHAKE" ]; then
  echo "CRITICAL: sem peers no $INTERFACE"
  exit 2
fi
AGORA=$(date +%s)
DIFERENCA=$(( (AGORA - ULTIMO_HANDSHAKE) / 60 ))
if [ $DIFERENCA -gt 5 ]; then
  echo "CRITICAL: último handshake há $DIFERENCA min"
  exit 2
else
  echo "OK: handshake recente ($DIFERENCA min)"
  exit 0
fi

Métricas úteis: bytes RX/TX por peer, tempo desde último handshake, endpoint atual. Todas disponíveis via wg show.

11. Backup e recuperação

O backup de uma configuração WireGuard é simples e deve seguir a regra 3‑2‑1‑1‑0:

• Arquivos — /etc/wireguard/ (inclui wg0.conf e chaves).
• Chaves privadas — críticas; se perdidas, é preciso gerar novo par e redistribuir as chaves públicas para todos os peers.
• Restauração — recriar os arquivos e ativar wg-quick@wg0.

Use restic ou Borg para automatizar.

12. Dimensionamento e performance

O WireGuard é extremamente eficiente — um único túnel pode atingir centenas de Mbps em hardware modesto. Para VPNs corporativas com dezenas de túneis, considere:

• CPU — qualquer processador moderno com AES-NI (embora WireGuard use ChaCha20, que é acelerado em alguns processadores).
• MTU — 1420 é o valor recomendado para evitar fragmentação em enlaces com overhead adicional (PPPoE, CGNAT).
• Num de peers — o WireGuard escala bem, mas para centenas de peers, considere automação (Ansible, scripts).

13. Comparativo com OpenVPN

Para ISP, o WireGuard é ideal em cenários de túneis entre PoPs e acesso remoto moderno; o OpenVPN continua relevante quando é necessária compatibilidade máxima (ex.: clientes com sistemas mais antigos) ou TCP (ex.: atravessar firewalls restritivos).

14. Troubleshooting

15. Glossário

16. Referências

• WireGuard — site oficial (wireguard.com) e whitepaper técnico.
• Documentação oficial Mikrotik RouterOS — módulo WireGuard nativo (v7+).
• Página relacionada: OpenVPN.

Conteúdo técnico independente. Nenhum trecho é cópia literal de fonte de terceiro.