feat: commit inicial das instrucoes e infraestrutura
This commit is contained in:
Rui
+111
@@ -0,0 +1,111 @@
|
||||
# 🛡️ 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 = <Chave_Publica_da_VPS_1>
|
||||
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 = <Chave_Publica_da_VPS_4>
|
||||
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!
|
||||
Reference in New Issue
Block a user