# Como construí minha própria infraestrutura para acessar MikroTik de clientes remotamente
Trabalhar com infraestrutura tem um problema que só aparece depois que você começa a ter vários clientes: administrar cada equipamento individualmente começa a consumir mais tempo do que deveria.
Um cliente liga:
“A internet caiu.”
Você precisa descobrir o IP público, verificar se existe NAT, descobrir se o roteador está atrás de outro roteador, tentar acessar o MikroTik, pedir acesso ao cliente, abrir uma porta, configurar redirecionamento...
E quando você percebe, perdeu meia hora apenas para conseguir chegar no equipamento.
Foi aí que comecei a pensar:
E se eu tivesse uma infraestrutura minha, centralizada, que funcionasse como uma porta de entrada para todos os MikroTik que instalo?
Foi assim que comecei a montar minha própria estrutura de acesso remoto.
O problema
Em instalações pequenas, é comum encontrar algo parecido com:
INTERNET
│
▼
[ Roteador/ONT da operadora ]
│
▼
[ MikroTik ]
│
├── PCs
├── Câmeras
├── Wi-Fi
└── Outros dispositivos
O problema aparece quando o MikroTik não recebe um IP público.
Você pode estar em:
Internet
│
CGNAT
│
Operadora
│
ONT
│
MikroTik
Nesse cenário, simplesmente abrir uma porta no MikroTik não resolve.
Eu precisava de outra abordagem.
A ideia
Em vez de tentar entrar diretamente no MikroTik do cliente, pensei em fazer o MikroTik iniciar uma conexão para uma infraestrutura que eu controlo.
A arquitetura passou a ser:
INTERNET
│
┌────────────┴────────────┐
│ │
▼ ▼
CLIENTE A CLIENTE B
│ │
[MikroTik] [MikroTik]
│ │
└──────────┬──────────────┘
│
▼
[VPN / SERVER]
│
▼
[Raspberry Pi]
│
▼
ADMINISTRAÇÃO
O servidor passa a ser o ponto central.
Eu não preciso mais depender de IP público em cada cliente.
Por que Raspberry Pi?
A primeira coisa que muita gente pensa quando ouve “servidor” é colocar uma máquina grande funcionando 24 horas.
Mas para essa função eu não precisava de um servidor poderoso.
Eu precisava de:
- baixo consumo;
- estabilidade;
- Linux;
- conexão permanente;
- possibilidade de executar WireGuard;
- SSH;
- scripts;
- monitoramento;
- backup;
- automação.
Um Raspberry Pi já consegue fazer isso tranquilamente.
E o mais interessante:
o custo de manter essa infraestrutura pode ser muito baixo.
WireGuard entrou na história
A solução que escolhi para a VPN foi o WireGuard.
A ideia ficou aproximadamente assim:
INTERNET
│
│
┌──────▼──────┐
│ SERVIDOR │
│ WireGuard │
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
Cliente 01 Cliente 02 Cliente 03
MikroTik MikroTik MikroTik
Cada cliente possui seu próprio peer.
Por exemplo:
Servidor
10.100.0.1
Cliente 01
10.100.0.2
Cliente 02
10.100.0.3
Cliente 03
10.100.0.4
Agora posso enxergar os equipamentos através da rede privada da VPN.
O que isso muda na prática?
Antes:
“Qual é o IP do cliente?”
“Está atrás de CGNAT?”
“Qual porta foi liberada?”
“Qual é o usuário?”
“Tem outro roteador antes do MikroTik?”
Depois:
VPN
│
├── 10.100.0.2 → Cliente 01
├── 10.100.0.3 → Cliente 02
├── 10.100.0.4 → Cliente 03
└── 10.100.0.5 → Cliente 04
O equipamento deixa de ser um endereço perdido na Internet.
Ele passa a ser simplesmente:
Cliente 04.
Mas existe um problema maior
Se eu fosse fazer isso de verdade, não queria simplesmente colocar todos os clientes dentro da mesma rede.
Isso seria uma péssima ideia.
Imagine:
Cliente A
│
├── consegue acessar Cliente B
├── consegue acessar Cliente C
└── consegue acessar Cliente D
Isso criaria uma superfície de ataque desnecessária.
A ideia correta é criar isolamento.
Por exemplo:
SERVIDOR
│
┌────────┼────────┐
│ │ │
▼ ▼ ▼
CLIENTE A CLIENTE B CLIENTE C
10.100.1 10.100.2 10.100.3
Cada cliente possui seu próprio espaço.
A partir daí veio outra ideia
Se eu já tenho um canal seguro até o MikroTik, por que continuar fazendo tudo manualmente?
Foi quando comecei a pensar em automação.
Eu poderia ter uma estrutura onde:
PAINEL
│
┌────────┴────────┐
│ │
Cliente 01 Cliente 02
│ │
MikroTik MikroTik
│ │
└────── VPN ──────┘
E através dessa estrutura poderia executar tarefas como:
✓ verificar conectividade
✓ verificar CPU
✓ verificar memória
✓ verificar versão RouterOS
✓ verificar interfaces
✓ verificar DHCP
✓ verificar usuários
✓ fazer backup
✓ coletar logs
✓ verificar disponibilidade
✓ executar comandos
O que mais me chamou atenção
A parte interessante não foi o WireGuard.
Foi perceber que eu estava transformando uma coleção de equipamentos independentes em uma infraestrutura administrável.
Antes:
Cliente 01
Cliente 02
Cliente 03
Cliente 04
Cliente 05
Depois:
MINHA INFRAESTRUTURA
│
┌────────────┼────────────┐
│ │ │
Cliente Cliente Cliente
│ │ │
MikroTik MikroTik MikroTik
│ │ │
└────────────┼────────────┘
│
VPN
│
SERVER
Isso muda completamente a maneira de pensar a manutenção.
E o melhor: isso não serve somente para MikroTik
A mesma arquitetura pode ser usada para administrar:
- Raspberry Pi
- servidores Linux
- NVRs
- sistemas de monitoramento
- equipamentos IoT
- aplicações internas
- câmeras
- gateways
- outros dispositivos de rede
O MikroTik é apenas uma das pontas.
Minha próxima evolução
O próximo passo é transformar essa infraestrutura em algo realmente automatizado.
Por exemplo:
NOVO CLIENTE
│
▼
Gerar identidade
│
▼
Gerar configuração WireGuard
│
▼
Configurar MikroTik
│
▼
Registrar cliente
│
▼
Monitoramento automático
│
▼
Backup periódico
Ou seja:
instalar um novo cliente deixa de ser um projeto e passa a ser um processo.
O que aprendi
A principal lição não foi “use WireGuard”.
Foi outra:
Quando você administra muitos equipamentos, o problema deixa de ser configurar o equipamento e passa a ser criar uma forma escalável de administrar todos eles.
Foi isso que começou a me fazer pensar diferente sobre infraestrutura.
Em vez de:
“Como acesso este MikroTik?”
comecei a pensar:
“Como faço para nunca mais precisar me preocupar
com a forma como esse MikroTik está conectado à Internet?”
Essa mudança de pensamento foi o que realmente tornou o projeto interessante.
Arquitetura final
No momento, a ideia ficou assim:
INTERNET
│
▼
┌─────────────────┐
│ SERVIDOR │
│ │
│ WireGuard │
│ Dashboard │
│ Monitoring │
│ Backups │
└────────┬────────┘
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
Cliente Cliente Cliente
01 02 03
│ │ │
MikroTik MikroTik MikroTik
Ainda estou evoluindo essa arquitetura, mas a ideia principal já está funcionando:
criar uma infraestrutura central para administrar equipamentos remotos sem depender de IP público em cada cliente.
E talvez essa seja a parte mais interessante de trabalhar com infraestrutura:
Você começa tentando resolver um problema de um cliente.
Quando percebe, está construindo uma solução para resolver o mesmo problema para todos os próximos.