Guia prático: como configurar WireGuard site-to-site entre duas VPS Debian passo a passo

Redes & Segurança · Por · Publicado em · Atualizado em · 9 min de leitura

Como configurar WireGuard site-to-site entre duas VPS Debian (passo a passo)
Foto: Rafael Minguet Delgado / Pexels

Aprenda como configurar WireGuard site-to-site entre duas VPS Debian passo a passo. Você vai instalar os pacotes, gerar chaves, criar os arquivos de configuração, abrir o firewall e testar o túnel. Focamos em um cenário simples e robusto, que você pode estender para sub-redes internas.

Pré-requisitos e topologia do túnel

Vamos conectar duas VPS Debian com um túnel WireGuard dedicado. Cada lado terá um endereço privado no túnel e, opcionalmente, poderá rotear sub-redes internas. Você precisará de acesso root ou sudo em ambas as VPS e da porta UDP do WireGuard liberada.

Antes de começar, confirme: IP público de cada VPS, DNS resolvendo bem, horário sincronizado e autorização para abrir UDP. Se ainda está escolhendo infraestrutura, veja quando optar por VPS, hospedagem compartilhada ou baremetal e como escolher o tamanho da VPS.

Topologia proposta: Site A ↔ Site B via WireGuard, rede do túnel 10.100.0.0/24. Cada VPS fala com a outra por IPs do túnel. Sub-redes locais são opcionais.

  • Duas VPS com Debian suportado e IP público (Site A e Site B)
  • Acesso SSH com sudo/root
  • Porta UDP do WireGuard aberta (padrão 51820)
  • Sincronização de hora (NTP) confiável
  • Conhecimento básico de firewall (iptables ou UFW)
Item Site A Site B
IP público <ip_publico_site_a> <ip_publico_site_b>
Endereço do túnel 10.100.0.1/24 10.100.0.2/24
Porta UDP 51820 51820

1) Instalar o WireGuard e habilitar IPv4 forwarding

Instale o WireGuard nos dois servidores e ative o encaminhamento IPv4. O forwarding é necessário se você pretende rotear tráfego além do próprio host. Executar atualizações e mudanças de rede pode derrubar a sessão SSH. Planeje uma janela segura.

# Em A e B
sudo apt update && sudo apt -y upgrade
sudo apt -y install wireguard wireguard-tools

# Verifique as versões e o módulo
wg --version
sudo modprobe wireguard || true

# Habilite IPv4 forwarding de forma persistente
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard-forward.conf
sudo sysctl -p /etc/sysctl.d/99-wireguard-forward.conf

# Opcional: confirme sincronização de horário (NTP)
timedatectl

2) Gerar pares de chaves em ambos os lados

Cada lado do túnel precisa de um par de chaves, privada e pública. A privada fica no servidor; a pública é compartilhada com o par. Proteja os arquivos de chave. O comando abaixo define permissões restritivas para não expor o material sensível.

# Em A e B: gere as chaves privadas e públicas
umask 077
sudo wg genkey | sudo tee /etc/wireguard/privatekey | sudo wg pubkey | sudo tee /etc/wireguard/publickey

# Mostre a chave pública para compartilhar com o outro lado
echo "Chave pública deste host:"
sudo cat /etc/wireguard/publickey

3) Configurar o Site A (wg0)

Crie o arquivo wg0.conf no Site A. Informe o endereço do túnel, a porta de escuta e o peer apontando para o Site B. Use a chave pública do Site B, o IP público dele e a porta UDP definida.

PersistentKeepalive ajuda quando há NAT no caminho. Ajuste a MTU apenas se notar sintomas de fragmentação ou perda.

# No Site A — substitua os placeholders antes de rodar
PRIV_A=$(sudo cat /etc/wireguard/privatekey)
PUB_B="<cole_a_chave_publica_do_site_B>"
ENDPOINT_B="<ip_publico_site_b>:51820"

sudo tee /etc/wireguard/wg0.conf > /dev/null <<EOF
[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = ${PRIV_A}

# Regras básicas de proteção da interface (opcional)
PostUp = sysctl -w net.ipv4.conf.all.rp_filter=2
PostDown = sysctl -w net.ipv4.conf.all.rp_filter=0

[Peer]
PublicKey = ${PUB_B}
AllowedIPs = 10.100.0.2/32
Endpoint = ${ENDPOINT_B}
PersistentKeepalive = 25
EOF

sudo chmod 600 /etc/wireguard/wg0.conf

4) Configurar o Site B (wg0)

Agora configure o wg0 no Site B, invertendo os endereços e usando a chave pública do Site A. O Endpoint aponta para o IP público do Site A com a porta UDP escolhida.

Mantenha AllowedIPs restrito ao necessário. Assim você evita roteamento indesejado e conflitos com rotas locais.

# No Site B — substitua os placeholders antes de rodar
PRIV_B=$(sudo cat /etc/wireguard/privatekey)
PUB_A="<cole_a_chave_publica_do_site_A>"
ENDPOINT_A="<ip_publico_site_a>:51820"

sudo tee /etc/wireguard/wg0.conf > /dev/null <<EOF
[Interface]
Address = 10.100.0.2/24
ListenPort = 51820
PrivateKey = ${PRIV_B}

PostUp = sysctl -w net.ipv4.conf.all.rp_filter=2
PostDown = sysctl -w net.ipv4.conf.all.rp_filter=0

[Peer]
PublicKey = ${PUB_A}
AllowedIPs = 10.100.0.1/32
Endpoint = ${ENDPOINT_A}
PersistentKeepalive = 25
EOF

sudo chmod 600 /etc/wireguard/wg0.conf

5) Abrir a porta UDP e ajustar o firewall/NAT

Libere a porta UDP do WireGuard e permita encaminhamento entre a interface wg0 e a interface WAN. Em servidores que usam iptables, você pode persistir as regras com iptables-persistent. Se preferir UFW, siga o seu fluxo de regras — há um guia de UFW aqui no site.

Se você só quer conectar as duas VPS entre si, NAT não é necessário. Para rotear sub-redes internas, veja a seção de rotas adicionais.

  • Porta padrão UDP 51820 (pode mudar, desde que ambos lados concordem)
  • Permitir FORWARD entre wg0 e a interface WAN
  • Persistir regras após reboot
# Em A e B — descubra a interface WAN
echo "Detectando interface WAN..."
WAN=$(ip route list default | awk '{print $5}' | head -n1)
echo "Interface WAN: ${WAN}"

# iptables (legacy) — abrir porta UDP 51820 e permitir forward
sudo iptables -A INPUT -i ${WAN} -p udp --dport 51820 -j ACCEPT
sudo iptables -A FORWARD -i wg0 -j ACCEPT
sudo iptables -A FORWARD -o wg0 -j ACCEPT

# Persistir regras (Debian)
sudo apt -y install iptables-persistent
sudo netfilter-persistent save

# Alternativa com UFW (se você usa UFW)
# sudo ufw allow 51820/udp
# sudo ufw route allow in on wg0 out on ${WAN}
# sudo ufw route allow in on ${WAN} out on wg0
# sudo ufw status verbose

6) Subir o túnel e validar a comunicação

Com tudo configurado, ative a interface wg0 e verifique o handshake. Use ping entre os IPs do túnel para testar conectividade. Se o handshake não acontecer, não prossiga sem corrigir.

Para complementar sua política de firewall com UFW, consulte o nosso guia de como configurar firewall no Ubuntu com UFW e adapte ao Debian.

  • Ativar e habilitar no boot com wg-quick
  • Verificar estado com wg show
  • Testar ping entre 10.100.0.1 e 10.100.0.2
# Em A e B: subir e habilitar no boot
sudo systemctl enable --now wg-quick@wg0

# Verificar status
sudo wg show
ip addr show wg0

# Testes básicos
# No Site A:
ping -c 4 10.100.0.2
# No Site B:
ping -c 4 10.100.0.1

# Opcional: testar rota
# traceroute 10.100.0.2

7) Solução de problemas e rotas adicionais (opcional)

Se não há handshake, revise chaves, portas e AllowedIPs. Quando há NAT ou IP dinâmico, PersistentKeepalive reduz o tempo de recuperação. MTU muito alta pode causar perda por fragmentação; ajuste se notar latências anormais.

Para alcançar sub-redes por trás das VPS, adicione as redes às AllowedIPs e, se não puder criar rotas estáticas do outro lado, aplique MASQUERADE na wg0 como último recurso.

Planeje monitorar o túnel e alertas. Se ainda está definindo o sistema operacional, veja como escolher a distribuição Linux do servidor.

  • Verifique DNS e resolução do Endpoint
  • Confirme que a porta UDP está realmente aberta
  • Cheque relógio/NTP e diferenças de horário
  • Ajuste MTU se houver fragmentação
  • Evite sobreposição de sub-redes em AllowedIPs
# Diagnóstico rápido
sudo journalctl -u wg-quick@wg0 -n 100 --no-pager
sudo wg show
sudo ss -lunp | grep 51820 || sudo ss -lun
sudo ip route show table main | grep -E 'wg0|default'
WAN=$(ip route list default | awk '{print $5}' | head -n1)
sudo tcpdump -ni ${WAN} udp port 51820

# Exemplo de wg0.conf com sub-redes atrás dos sites (opcional)
# Suponha LAN_A=10.10.1.0/24 (Site A) e LAN_B=10.10.2.0/24 (Site B)
# Site A (trecho):
# [Interface]
# Address = 10.100.0.1/24
# PostUp = iptables -t nat -A POSTROUTING -s 10.10.1.0/24 -o wg0 -j MASQUERADE
# PostDown = iptables -t nat -D POSTROUTING -s 10.10.1.0/24 -o wg0 -j MASQUERADE
# [Peer]
# PublicKey = <PUB_B>
# AllowedIPs = 10.100.0.2/32, 10.10.2.0/24

# Site B (trecho):
# [Interface]
# Address = 10.100.0.2/24
# PostUp = iptables -t nat -A POSTROUTING -s 10.10.2.0/24 -o wg0 -j MASQUERADE
# PostDown = iptables -t nat -D POSTROUTING -s 10.10.2.0/24 -o wg0 -j MASQUERADE
# [Peer]
# PublicKey = <PUB_A>
# AllowedIPs = 10.100.0.1/32, 10.10.1.0/24

# Após ajustar, reinicie a interface
# sudo systemctl restart wg-quick@wg0

Perguntas frequentes

Posso usar outra porta além de 51820 para o WireGuard?

Pode. Escolha qualquer porta UDP livre e use o mesmo valor em ambos os lados. Lembre-se de abrir a porta no firewall e ajustar o Endpoint. Em provedores de nuvem, confira também regras de segurança na console.

O que devo colocar em AllowedIPs?

Inclua os destinos que devem atravessar o túnel. Para conectar apenas os IPs do túnel, use o /32 do par remoto. Para alcançar sub-redes atrás do peer, adicione as redes remotas. Evite sobreposição com rotas locais.

E se o IP público da VPS mudar?

Use um nome DNS no Endpoint em vez de IP. O WireGuard resolve periodicamente conforme o TTL. Com IPs muito dinâmicos, PersistentKeepalive ajuda a manter o caminho ativo. Em mudanças bruscas, reiniciar a interface acelera a reconexão.

Qual MTU devo usar no WireGuard?

O padrão funciona na maioria dos cenários. Se houver perda ou lentidão por fragmentação, teste valores entre 1280 e 1420 no bloco [Interface] como MTU=valor. Ajuste nos dois lados e valide com testes de pacote sem fragmentação.

Uso nftables. Os comandos com iptables funcionam?

Em Debian recente, iptables pode usar backend nftables. Os comandos tendem a funcionar, mas mantenha uma única abordagem por servidor para evitar confusão. Se você já usa regras nftables nativas, replique as permissões equivalentes lá.

É seguro expor a porta do WireGuard na internet?

WireGuard usa criptografia moderna e não responde a pacotes inválidos. Ainda assim, mantenha o sistema atualizado e limite a origem por firewall se desejar. A segurança depende também de boas chaves e configurações corretas.

Precisa adaptar o túnel para múltiplos sites ou rotas complexas?

Posso ajudar a revisar sua topologia, ajustar firewall e automatizar a configuração para produção.

Falar sobre seu cenário

Veja também