# 🛡️ 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`):**
```ini
[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`):
```ini
[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]`:
   ```ini
   [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]`:
   ```ini
   [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.

