Rui
154 lines
7.0 KiB
Markdown
154 lines
7.0 KiB
Markdown
# 🛡️ 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.
|
|
|