ruicesar/instrucoes_gerais
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Page: VPN WireGuard Setup
Pages
Arquitetura Geral Auto Cura Self Healing Clube67 Baileys Swap Clube67 Development Clube67 Plano de Negocio Comandos Agentes Referencia Home Instrucoes Antigravity Instrucoes Claude Loop Auto Cura Self Healing Otimizacao PostgreSQL Protocolo Agentes Swarm Protocolo Deploy e Staging SSH Calendar Monitor ScoreOdonto Arquitetura ScoreOdonto Deploy Seguranca Deploy User Setup VPS1 Production Setup VPS3 Brain Setup VPS4 Lab Sincronizacao Instrucoes Tuning Database e DragonflyDB VPN WireGuard Setup v1.0.0 v1.0.1 v1.0.2 v1.0.3 v1.0.4 v1.0.5 v1.0.6 v1.0.7 v1.0.8 v1.0.9 v1.1.0 v1.1.1
Clone
1
VPN WireGuard Setup
ruicesar edited this page 2026-05-17 08:16:08 +02:00
Table of Contents

🛡️ Plano de Contingência e Alta Disponibilidade da VPN

Este documento descreve detalhadamente as soluções propostas para evitar o bloqueio de acesso e garantir a continuidade da comunicação entre os servidores (VPS 3, 4 e 5) caso o servidor central de VPN (VPS 1) sofra uma queda ou falha de sistema.

🚨 O Problema: O Ponto Único de Falha (SPOF)

Atualmente, a rede privada utiliza uma topologia em Estrela (Hub-and-Spoke), onde a VPS 1 é o Hub central. Se a VPS 1 cair:

  1. A rede VPN criptografada (10.99.0.0/24) deixa de funcionar.
  2. A comunicação interna entre os servidores (como o envio de dados do app para o banco de dados na VPS 3) é interrompida.
  3. Como o SSH padrão (porta 22) está fechado na internet pública para as outras VPSs, você fica impedido de acessar os servidores via terminal de forma convencional, necessitando recorrer ao Console VNC no painel web da Contabo.

Abaixo estão as três soluções de contingência, ordenadas de forma prática.

🚪 Opção A: Estratégia Sênior Zero-Trust (Recomendado - 🛡️ Segurança Absoluta)

Esta abordagem elimina qualquer necessidade de expor portas SSH na internet pública (mesmo portas altas secundárias). Em vez de manter uma porta pública de "fallback" (vulnerável a ruído de scanners e bots), a administração e o tráfego de diagnóstico são restringidos a 100% de conexões internas criptografadas por VPN WireGuard.

Como mitigar o risco de lockout (Bloqueio de Acesso):

Para evitar o isolamento de acesso caso o servidor central de VPN caia, adota-se uma trilha tripla de contingência:

  1. Console VNC nativo do Provedor (Ex: Contabo): Mantido ativo na console web do provedor como canal de recuperação direta de emergência e console físico absoluto em caso de desastre.
  2. Peers WireGuard Redundantes (Multi-Device): Configuração de múltiplos dispositivos do administrador autorizados no Hub:
    • Peer 1: Notebook Principal.
    • Peer 2: Notebook Reserva, celular corporativo ou VM dedicada.
  3. Backups Offline de Chaves e Configurações: Armazenamento das configurações de VPN do Wireguard (wg0.conf) de forma cifrada offline (Ex: Pendrive criptografado, Cofre físico ou Vault de segurança como Bitwarden/1Password).

Vantagens dessa Abordagem:

  • Zero Exposição Pública: Nenhuma porta além de 80 e 443 (na VPS 1) e da porta UDP do WireGuard ficam abertas na internet.
  • Redução de Overhead: Conectar de ferramentas administrativas (como DBeaver ou SSH direto) diretamente via IP da VPN (10.99.0.3) sem necessidade de fazer túneis SSH adicionais desnecessários sobre o canal VPN.

🕸️ Opção B: Comunicação Direta entre as VPSs (Full-Mesh - 🛠️ Intermediário)

Consiste em criar túneis diretos do WireGuard entre as VPSs 3, 4 e 5, dispensando a necessidade de a VPS 1 estar online para que elas conversem entre si.

Como configurar as rotas diretas:

Para fazer isso, precisamos adicionar as chaves públicas e os IPs de endpoint físicos das outras VPSs diretamente no arquivo /etc/wireguard/wg0.conf de cada uma das máquinas.

Exemplo de configuração na VPS 3 (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.99.0.3/24
PrivateKey = <Chave_Privada_da_VPS_3>
ListenPort = 52830

# Peer 1: VPS 1 (Hub Central)
[Peer]
PublicKey = jUWnuc+82vQ6kLMSI7W1i7hBRBgQKcaSZ8yJy56QSUw=
AllowedIPs = 10.99.0.1/32
Endpoint = 158.220.109.237:51820
PersistentKeepalive = 25

# Peer 2: VPS 4 (Conexão Direta - Redundância)
[Peer]
PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0=
AllowedIPs = 10.99.0.4/32
Endpoint = <IP_Publico_da_VPS_4>:51820
PersistentKeepalive = 25

# Peer 3: VPS 5 (Conexão Direta - Redundância)
[Peer]
PublicKey = <Chave_Publica_da_VPS_5>
AllowedIPs = 10.99.0.5/32
Endpoint = <IP_Publico_da_VPS_5>:51820
PersistentKeepalive = 25

Vantagens:

  • Se a VPS 1 quebrar, as conexões de banco de dados (10.99.0.3) das VPSs 4 e 5 continuam funcionando de forma 100% direta e automática.

🔄 Opção C: VPN Secundária de Backup (Failover Hub - 🛠️ Avançado)

Consiste em configurar a VPS 3 (Banco de Dados) ou a VPS 5 (CRM) como um segundo servidor de VPN (redundante) rodando sob uma interface separada (ex: wg1), criando um caminho de fuga independente.

Estrutura de Rede da VPN de Backup:

  • VPN Principal (wg0): Hub na VPS 1, rede 10.99.0.0/24.
  • VPN de Backup (wg1): Hub na VPS 3, rede 10.98.0.0/24.

Configuração da VPS 3 como Hub Redundante (/etc/wireguard/wg1.conf):

[Interface]
Address = 10.98.0.3/24  # IP da VPS 3 na nova rede de backup
PrivateKey = <Chave_Privada_de_Backup_da_VPS_3>
ListenPort = 51821      # Porta diferente para não colidir com o wg0

# Peer 1: Seu Notebook
[Peer]
PublicKey = <Chave_Publica_do_Seu_Notebook>
AllowedIPs = 10.98.0.10/32

# Peer 2: VPS 4
[Peer]
PublicKey = <Chave_Publica_de_Backup_da_VPS_4>
AllowedIPs = 10.98.0.4/32

# Peer 3: VPS 5
[Peer]
PublicKey = <Chave_Publica_de_Backup_da_VPS_5>
AllowedIPs = 10.98.0.5/32

Vantagens:

  • Se a VPS 1 desaparecer da internet por completo, basta que você e seus sistemas ativem a interface wg1 do WireGuard. Toda a sua infraestrutura continuará conectada em questão de segundos através da nova rede segura comandada pela VPS 3!

⚡ Otimização de Performance, Jitter e Latência (Ajuste de MTU)

Se você perceber oscilações de latência (jitter) elevadas (ex: ping variando de 2ms a 700ms) entre os servidores na interface wg0, o motivo é a fragmentação de pacotes causada pelo limite de tamanho físico da infraestrutura da Contabo.

Para resolver isso de forma definitiva e estabilizar a latência para ~1ms a 3ms constantes, aplicamos a otimização de MTU (Maximum Transmission Unit) em toda a malha.

📋 Configuração de MTU Recomendada:

Definimos o MTU = 1360 (ou 1280 para máxima resiliência) em todos os arquivos de configuração do WireGuard (/etc/wireguard/wg0.conf).

Como aplicar nos Servidores:

  1. Na VPS 3 (Data Appliance - JÁ IMPLEMENTADO): Edite /etc/wireguard/wg0.conf e adicione MTU = 1360 sob [Interface]:

    [Interface]
Address = 10.99.0.3/24
PrivateKey = <Chave_Privada>
ListenPort = 52830
MTU = 1360

    Reinicie o serviço: sudo systemctl restart wg-quick@wg0

  2. Na VPS 1 (Hub Central - REQUER APLICAR): Edite /etc/wireguard/wg0.conf e adicione MTU = 1360 sob [Interface]:

    [Interface]
Address = 10.99.0.1/24
PrivateKey = <Chave_Privada>
ListenPort = 51820
MTU = 1360

    Reinicie o serviço: sudo systemctl restart wg-quick@wg0

  3. Nas VPSs 4 e 5 (Staging e CRM - REQUER APLICAR): Repita o mesmo procedimento adicionando MTU = 1360 sob [Interface] em seus respectivos /etc/wireguard/wg0.conf e reinicie a interface.

Tip

Atenção: Para que a otimização funcione plenamente e as oscilações cessem, ambas as pontas do túnel (ex: VPS 3 e VPS 1) devem estar com o mesmo valor de MTU configurado e reiniciados.