VPN site-to-site com WireGuard: ligar duas redes (guia 2026)

Aviso de afiliação — Este artigo contém links de afiliado da Contabo. Se encomendar um VPS através deles, ganhamos uma comissão sem custo adicional para si. Todos os comandos e configurações abaixo estão documentados a partir das fontes oficiais do WireGuard e escritos para serem reproduzíveis nas suas próprias máquinas.

Uma VPN site-to-site une duas redes inteiras para que se comportem como uma só. Cada host da LAN do escritório consegue alcançar cada host da LAN de casa — o seu NAS, uma impressora, um hipervisor, uma base de dados — sem instalar um cliente VPN em cada dispositivo. O WireGuard torna isto leve e rápido: uma única porta UDP, um punhado de linhas de configuração, criptografia em espaço de kernel. Este guia constrói um túnel WireGuard site-to-site funcional do zero e depois explica as três coisas que se erram sempre: AllowedIPs, o encaminhamento de IP e o encaminhamento dos hosts.

Vamos usar uma topologia concreta e comum: o Site A é uma LAN doméstica ou de escritório por trás de NAT (sem IP público utilizável), e o Site B é um VPS com IPv4 público a servir de hub sempre ativo. A mesma configuração também une duas casas, dois escritórios ou dois data centers — só mudam as sub-redes.

Site-to-site vs road-warrior: o que muda realmente

Se já configurou o WireGuard para um portátil, 90 % disto ser-lhe-á familiar. A mudança de mentalidade é pequena mas crucial:

• Road-warrior (acesso remoto): um dispositivo entra na rede. O seu peer anuncia um único endereço de túnel — AllowedIPs = 10.66.66.2/32.
• Site-to-site: uma rede inteira entra. O peer anuncia a sub-rede LAN que tem por trás — AllowedIPs = 10.66.66.2/32, 192.168.10.0/24 — e a box WireGuard encaminha por cada host dessa LAN.

Tudo o resto — chaves, handshake, porta UDP — é idêntico. Se o seu handshake nunca se completa, as causas são as mesmas de qualquer túnel; percorra a lista de soluções do handshake WireGuard antes de culpar a parte site-to-site.

Planeie primeiro o espaço de endereçamento (5 minutos que poupam horas)

Antes de tocar numa configuração, anote três intervalos. Errar aqui é a causa número um de um túnel que liga mas não transporta tráfego dos hosts.

A regra dura: as duas LAN não se podem sobrepor. Se ambos os lados usarem hoje 192.168.1.0/24, renumere um agora. Um host não consegue encaminhar para uma sub-rede remota idêntica à sua — vai tratar o endereço como local e nunca entregar o pacote ao WireGuard. Se a matemática das sub-redes lhe escapa, a nossa explicação do que é uma sub-rede cobre o CIDR de forma simples.

Passo 1 — Provisionar o hub (Site B, o VPS)

O Site B precisa de um IPv4 público e de uma porta UDP aberta. Usamos um Contabo Cloud VPS 10 (4 vCPU, 8 GB RAM, 75 GB NVMe) a 5,50 €/mês no plano de 12 meses — sobredimensionado para um túnel, confortável se também correr outros serviços. Se ainda não tiver um VPS, obtenha o Contabo Cloud VPS 10; escolha uma região perto do site que envia mais tráfego. Para uma instalação limpa do WireGuard nele, siga o guia passo a passo Contabo + WireGuard e depois volte aqui para o encaminhamento site-to-site.

Instale o WireGuard e gere as chaves no VPS:

sudo apt update && sudo apt install -y wireguard
umask 077
wg genkey | tee siteB.key | wg pubkey > siteB.pub

Passo 2 — Configurar o router WireGuard no Site A

A box WireGuard do Site A é qualquer máquina Linux sempre ligada da LAN — um Raspberry Pi, uma pequena VM, um portátil velho. Não precisa de IP público; disca para o VPS. Gere as suas chaves do mesmo modo:

wg genkey | tee siteA.key | wg pubkey > siteA.pub

Esta máquina torna-se o gateway da sub-rede remota, por isso tem de encaminhar pacotes entre a sua interface LAN e a interface WireGuard.

Passo 3 — As duas configurações

Eis o túnel inteiro. Repare como o AllowedIPs de cada lado lista a LAN do outro site — é essa linha que transforma uma ligação ponto-a-ponto numa ligação rede-a-rede.

Site B — o hub VPS (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <siteB.key>
# forward + masquerade para que os hosts do Site A também cheguem à internet via VPS
PostUp = sysctl -w net.ipv4.ip_forward=1
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]
# Site A
PublicKey = <siteA.pub>
AllowedIPs = 10.66.66.2/32, 192.168.10.0/24

Site A — o router LAN (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.2/24
PrivateKey = <siteA.key>
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT

[Peer]
# Site B (o hub VPS)
PublicKey = <siteB.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Dois detalhes que importam:

• PersistentKeepalive = 25 fica no lado por trás de NAT (Site A). Envia um pacote minúsculo a cada 25 segundos para que o router doméstico mantenha o caminho UDP aberto e o VPS possa sempre responder.
• Endpoint só aparece no bloco de peer do Site A — é o Site A que liga ao VPS. O VPS aprende o endereço do Site A quando o primeiro pacote chega, por isso o seu bloco de peer não tem Endpoint.

Levante ambos os túneis com sudo wg-quick up wg0 e verifique sudo wg show. Um latest handshake de menos de dois minutos em ambos os lados significa que a ligação está viva.

Passo 4 — O passo que toda a gente esquece: o encaminhamento dos hosts

É aqui que a maioria dos túneis site-to-site encrava. Os routers fazem ping em 10.66.66.x, mas um portátil do Site A continua sem alcançar um NAS do Site B. Porquê? Porque os restantes hosts de cada LAN não sabem que a box WireGuard é a porta para a sub-rede remota. Enviam o pacote para o gateway predefinido, que não tem rota para 192.168.20.0/24, e ele morre.

Tem duas formas limpas de resolver:

1. Rota estática no gateway da LAN (a melhor). No router principal do Site A, adicione uma rota estática: destino 192.168.20.0/24, gateway = o IP LAN da box WireGuard do Site A (ex.: 192.168.10.5). Faça o espelho no Site B. Agora cada host herda a rota automaticamente. A maioria dos routers domésticos e profissionais suporta rotas estáticas no painel de administração.
2. Rotas estáticas por host. Se não puder tocar no router, adicione uma rota em cada máquina que precise de acesso ao outro site:

# num host do Site A, alcançar a LAN do Site B via a box WireGuard local
sudo ip route add 192.168.20.0/24 via 192.168.10.5

Se a box WireGuard for o gateway predefinido da sua LAN, pode saltar isto por completo — já encaminha. Conceptualmente é um problema de encaminhamento, não de VPN; a mesma lógica do encaminhamento de portas mas aplicada a uma sub-rede inteira em vez de uma única porta.

Passo 5 — Firewall no caminho de encaminhamento

Encaminhar sem regra de firewall significa deixar passar ou nada ou tudo. Seja explícito. No hub VPS, o PostUp acima já aceita o tráfego encaminhado de wg0; aperte-o se quiser que só certas sub-redes falem:

# permitir só LAN Site A <-> LAN Site B, descartar o resto
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -i wg0 -j ACCEPT
iptables -A FORWARD -s 192.168.20.0/24 -d 192.168.10.0/24 -o wg0 -j ACCEPT

Torne as regras persistentes (iptables-save, ou netfilter-persistent save em Debian/Ubuntu) para que sobrevivam a um reinício. A única porta UDP também tem de estar aberta à frente do VPS — veja que porta o WireGuard usa e como a abrir se o handshake nunca arrancar.

Verificar o caminho completo

Execute isto por ordem e pare no primeiro falhanço:

1. Túnel ativo? sudo wg show em ambas as extremidades → latest handshake recente, transfer diferente de zero.
2. Router a router? Da box WireGuard do Site A: ping 10.66.66.1. Falha → é um problema de túnel, não de site-to-site.
3. Router para LAN remota? Da box do Site A: ping 192.168.20.1. Falha → AllowedIPs ou ip_forward no Site B.
4. Host para host remoto? De um portátil do Site A: ping 192.168.20.50. Falha aqui mas o passo 3 funcionava → encaminhamento dos hosts (passo 4).

Esta escada de quatro linhas isola em menos de um minuto a camada exata que está partida.

Quando adicionar mais sites — hub-and-spoke

Para unir três redes ou mais, mantenha o VPS como hub central e adicione cada nova LAN como peer spoke nele. Cada spoke lista todas as outras sub-redes LAN no seu AllowedIPs (encaminhadas via hub), e o hub lista a LAN de cada spoke. Isto mantém-se simples até um punhado de sites. Para além disso — ou se quiser rotação automática de chaves, ACL e atravessamento de NAT sem IP público em nenhum lado — um plano de controlo em malha como o Tailscale ou o Headscale dá menos trabalho do que editar os peers à mão; pondere-o na nossa comparação Tailscale vs WireGuard self-host.

Porquê auto-hospedar o hub em vez de um serviço gerido

Uma ligação site-to-site é exatamente onde possuir a box compensa: sem preço por posto, sem limite de dados, sem terceiros no caminho entre as suas duas redes. Um Contabo Cloud VPS 10 a 5,50 €/mês oferece IPv4 público, root completo, tráfego ilimitado (uso justo) e a liberdade de abrir a única porta UDP de que precisa — o hub sempre ativo ideal para ligar os seus sites. Construa-o uma vez e corre durante anos.

Para aprofundar

• VPN auto-hospedada na Contabo: guia completo de WireGuard 2026
• O handshake WireGuard não se completa: a lista completa de soluções
• O que é uma sub-rede? Subnetting e CIDR explicados
• O encaminhamento de portas explicado: aceder a um servidor atrás do router
• Tailscale vs WireGuard self-host: qual escolher
• Modelos de configuração WireGuard prontos a usar 2026

Fontes e referências:

• Whitepaper WireGuard — Jason A. Donenfeld
• Quickstart WireGuard e docs wg-quick
• Manpages wg(8) e wg-quick(8)
• Arch Wiki — WireGuard (encaminhamento & site-to-site)

Publicado em 2026-06-26. Topologia validada em Debian 12 e Ubuntu 24.04 com um hub Contabo Cloud VPS 10 e um router LAN Raspberry Pi. As suas sub-redes, modelos de router e o comportamento NAT do seu ISP serão diferentes — confirme sempre cada camada com wg show, ping e ip route antes de considerar uma configuração como final.

Lembrete: executar o WireGuard e auto-hospedar uma VPN é legal na UE, nos EUA, no Canadá e na maioria dos países democráticos. A VPNSmith publica este conteúdo para fins educativos.