Cara, excelentes perguntas. E principalmente a 4 é uma observação que eu mesmo tive durante a montagem, porque existe uma diferença importante entre acesso remoto e monitoramento da queda do acesso.
Vou responder por partes:
1. Isolamento dos clientes
Não considero a subnet sozinha como uma camada de segurança suficiente.
A ideia é que cada cliente tenha sua própria rede dentro da VPN, por exemplo:
Servidor
10.100.0.1
Cliente 01 → 10.100.1.0/24
Cliente 02 → 10.100.2.0/24
Cliente 03 → 10.100.3.0/24
Mas no servidor eu também colocaria regras de firewall para impedir o tráfego lateral entre os peers.
Ou seja, o fato de o Cliente 01 estar em uma subnet diferente do Cliente 02 não significa automaticamente que ele não consiga rotear até ela. Se o servidor estiver fazendo o roteamento entre essas redes, preciso bloquear isso explicitamente.
A ideia é:
SERVER
│
┌──────────┼──────────┐
│ │ │
Cliente 01 Cliente 02 Cliente 03
│ │ │
X───────────X───────────X
sem acesso lateral
O servidor só deve permitir o que realmente for necessário.
2. CGNAT + persistent-keepalive
Sim, esse é um ponto importante.
No cenário em que o MikroTik está atrás de NAT/CGNAT, o problema não é exatamente o WireGuard não funcionar, mas o mapeamento NAT poder expirar quando fica muito tempo sem tráfego.
Nesse caso o persistent-keepalive é justamente uma das coisas que considero na configuração dos peers que estão atrás de NAT.
Algo como:
persistent-keepalive=25
faz o peer enviar tráfego periodicamente para manter o mapeamento.
Ainda estou tratando isso como parte do padrão de provisionamento, porque quero que o processo seja automático e não depender de lembrar dessa configuração em cada instalação.
3. Raspberry Pi como ponto central
Essa é provavelmente a maior fragilidade da arquitetura inicial.
Se eu tiver:
INTERNET
│
SERVER
│
┌────────────┼────────────┐
│ │ │
Cliente 01 Cliente 02 Cliente 03
e o servidor cair, perco o acesso remoto a todos.
Por isso não considero o Raspberry Pi o "ponto final" da arquitetura. Ele é o primeiro estágio.
A ideia é evoluir para:
SERVIDOR A
/ \
/ \
Cliente 01 Cliente 02
\ /
\ /
SERVIDOR B
ou pelo menos ter um segundo ponto de acesso/backup para os clientes mais críticos.
No meu caso estou começando simples justamente para validar a arquitetura antes de colocar alta disponibilidade em cima.
4. Essa foi a melhor pergunta
Você está certo.
Se o cliente liga falando:
"Minha internet caiu completamente."
e o MikroTik depende daquela mesma Internet para estabelecer o túnel, eu não consigo magicamente entrar nele através da VPN.
Se:
INTERNET DO CLIENTE
X
│
MikroTik
X
WireGuard
não existe caminho físico para o servidor.
Então a VPN resolve principalmente situações como:
- configuração;
- lentidão;
- diagnóstico;
- firewall;
- DHCP;
- DNS;
- Wi-Fi;
- monitoramento;
- alterações de configuração;
- análise de logs;
- problemas que ainda deixam o MikroTik conectado.
Para queda total do link, preciso de outra estratégia se quiser diagnóstico remoto.
E foi justamente essa questão que me fez pensar que o projeto não deveria ser somente "VPN para acessar MikroTik".
Quero transformar isso em uma infraestrutura de monitoramento + acesso remoto.
Por exemplo, se o túnel cair, o servidor já pode saber:
09:41:02 → Cliente online
09:41:15 → perda de comunicação
09:41:20 → peer não responde
09:41:30 → cliente offline
E antes disso eu posso ter informações como:
último handshake
último tráfego
CPU
memória
interfaces
logs
estado das rotas
Isso não resolve uma queda física da Internet, obviamente, mas ajuda muito a diferenciar:
Internet caiu
X
MikroTik travou
X
WireGuard caiu
X
DNS parou
X
rota foi alterada
X
equipamento desligou
Essa parte de monitoramento ainda é uma das coisas que estou evoluindo no projeto.
Sobre provisionar um peer novo:
Hoje eu não quero depender de configuração manual.
A ideia é justamente chegar em algo assim:
Novo cliente
↓
Gerar chave
↓
Definir IP do peer
↓
Gerar configuração
↓
Aplicar no MikroTik
↓
Cadastrar no servidor
↓
Monitorar
No começo é perfeitamente possível fazer isso através de .rsc, mas o objetivo é automatizar a geração.
Por exemplo, eu cadastro:
CLIENTE = 004
IP = 10.100.4.2
e o sistema gera a configuração correspondente.
Então, resumindo: você apontou exatamente algumas das limitações que eu estou tentando resolver na segunda etapa do projeto. A primeira versão é basicamente "preciso conseguir chegar nos equipamentos mesmo atrás de CGNAT". A próxima é transformar isso em uma plataforma de provisionamento + monitoramento + backup + diagnóstico.
E valeu pelas perguntas, porque a 4 principalmente é uma distinção que acho que vale colocar no próprio post. A VPN não faz milagre quando o link do cliente morreu; ela resolve o problema de como chegar no equipamento enquanto ainda existe conectividade.