Monte um cluster privado de VPS com uma malha WireGuard

Resposta curta: para transformar vários VPS num cluster privado, dê a cada nó VPS uma interface WireGuard com um endereço de uma mesma sub-rede privada, adicione todos os outros nós como `[Peer]` com seu `Endpoint` público e um `/32` em `AllowedIPs`, libere a porta UDP 51820 apenas para os seus próprios nós e vincule bancos de dados e serviços internos ao endereço do `wg0` em vez do IP público. Até cerca de dez nós, isso é fácil de manter à mão ou com um template; acima disso, use ferramentas que gerem e distribuam as configurações.

Este guia parte do princípio de que você já conhece o básico do guia de VPN WireGuard e já reforçou o SSH em todos os nós como no guia de hardening de SSH; para alcançar os nós por um bastion sem agent forwarding, veja o guia de StrictModes e agent forwarding.

Plano de endereçamento para os nós da VPN

Escolha uma faixa privada que não conflite com nada que você já usa (LAN de casa, Docker, faixas de pods do Kubernetes). Um `/24` basta para um cluster pequeno e mantém os endereços legíveis. Atribua a cada nó um endereço fixo e mantenha o plano sob controle de versão, porque todas as configurações derivam dele.

Configuração por peer em cada nó VPS

Numa malha completa, cada nó fala diretamente com todos os outros, então cada configuração tem um `[Interface]` e N-1 seções `[Peer]`. Quatro nós significam seis túneis no total; dez nós significam 45. Todo nó tem IP público, então o `PersistentKeepalive` geralmente não é necessário; os detalhes estão no guia de keepalive e PresharedKey.

1. 01.Em cada nó, rode `apt install wireguard` e depois `umask 077; wg genkey | tee /etc/wireguard/wg0.key | wg pubkey > /etc/wireguard/wg0.pub`.
2. 02.Reúna todas as chaves públicas e o plano de endereços num só lugar.
3. 03.Opcionalmente, gere uma chave `wg genpsk` por par de nós como proteção pós-quântica.
4. 04.Escreva o `/etc/wireguard/wg0.conf` em cada nó como mostrado abaixo.
5. 05.Rode `systemctl enable --now wg-quick@wg0` e confira no `wg show` se há um handshake recente com cada peer.

# /etc/wireguard/wg0.conf on node1
[Interface]
Address = 10.88.0.1/24
ListenPort = 51820
PrivateKey = <node1 private key>

[Peer]
# node2
PublicKey = <node2 public key>
Endpoint = 203.0.113.12:51820
AllowedIPs = 10.88.0.2/32

[Peer]
# node3
PublicKey = <node3 public key>
Endpoint = 203.0.113.13:51820
AllowedIPs = 10.88.0.3/32

[Peer]
# node4
PublicKey = <node4 public key>
Endpoint = 203.0.113.14:51820
AllowedIPs = 10.88.0.4/32

Como o AllowedIPs funciona numa malha

O `AllowedIPs` faz dois trabalhos ao mesmo tempo. Na saída, é uma tabela de roteamento: pacotes para `10.88.0.3` vão para o peer que lista `10.88.0.3/32`. Na entrada, é uma lista de acesso: um pacote vindo daquele peer só é aceito se o endereço de origem estiver dentro do `AllowedIPs` dele. É por isso que cada peer recebe exatamente o próprio `/32`, e não o `/24` inteiro.

O `/24` na linha `Address` apenas cria a rota do kernel para a sub-rede no `wg0`; o WireGuard então escolhe o peer certo para cada destino.

• ▹Dois peers nunca devem compartilhar faixas de `AllowedIPs` sobrepostas na mesma interface; a última vence.
• ▹Se um nó também roteia uma sub-rede privada (por exemplo o Docker no node3), adicione essa sub-rede ao `AllowedIPs` do node3 nos outros nós.
• ▹Não coloque `0.0.0.0/0` num peer da malha, a menos que você queira de fato que todo o tráfego saia por aquele nó.

Firewall: só os seus nós alcançam o túnel

O WireGuard não responde a pacotes não autenticados, mas limitar a porta UDP 51820 aos IPs conhecidos dos nós ainda reduz o ruído. Dentro do túnel, abra só as portas de que cada serviço precisa. Este exemplo de nftables para Debian 12/13 e Ubuntu 24.04 vai em `/etc/nftables.conf`; carregue-o com `nft -f /etc/nftables.conf` e ative o `nftables.service`. Mantenha uma sessão SSH aberta enquanto testa.

table inet filter {
  set mesh_peers {
    type ipv4_addr
    elements = { 203.0.113.11, 203.0.113.12, 203.0.113.13, 203.0.113.14 }
  }
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    meta l4proto { icmp, ipv6-icmp } accept
    tcp dport 22 accept
    udp dport 51820 ip saddr @mesh_peers accept
    iifname "wg0" ip saddr 10.88.0.0/24 tcp dport { 5432, 6379, 9100 } accept
  }
}

Vincule os serviços à interface wg

O firewall é uma camada; a segunda é simplesmente não escutar no endereço público. Vincule os serviços internos ao endereço `wg0` do nó para que um erro no firewall não os exponha. Como o `wg0` precisa existir antes de o serviço se vincular, ordene as units com um drop-in do systemd, ou permita o vínculo a endereços que ainda não estão ativos com `net.ipv4.ip_nonlocal_bind = 1`.

# PostgreSQL on node3: postgresql.conf
listen_addresses = '10.88.0.3'
# pg_hba.conf
host  all  all  10.88.0.0/24  scram-sha-256

# Redis: /etc/redis/redis.conf
bind 10.88.0.3

# systemctl edit postgresql  (repeat for other services)
[Unit]
[email protected]
[email protected]

Note · Confira o resultado com `ss -tlnp`: os serviços internos devem mostrar `10.88.0.x`, nunca `0.0.0.0` nem o IP público.

Escalando: quando passar a usar ferramentas

Uma malha escrita à mão funciona bem enquanto o número de nós é pequeno e as mudanças são raras. Cada nó novo significa editar todas as configurações existentes, então o trabalho cresce de forma quadrática. Quando isso virar um fardo, gere as configurações em vez de escrevê-las.

Na NoctisNode, todos os novos nós VPS são implantados em FI-1 (Finlândia), cada um com IPv4 dedicado e porta de 1 Gbps sem medição, e a cobrança por hora mais a API para agentes (com TTL de autodestruição) tornam barato adicionar e remover nós de teste. Os planos começam no nível Wisp; veja os planos VPS.

Perguntas frequentes