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.