Guia de VPN IPsec Site-to-Site MikroTik

Resumo Uma VPN IPsec site-to-site no MikroTik criptografa o tráfego entre duas redes inteiras — a matriz e uma filial, um NOC e um site de torre — de modo que os hosts de cada LAN alcancem a outra como se fossem locais. Este guia configura os dois roteadores no RouterOS v7: o peer IKEv2, a identity com chave pré-compartilhada, o proposal da Fase 2, a policy do túnel, a regra de bypass de NAT que derruba a maioria das primeiras tentativas e as regras de firewall e verificações que confirmam que o túnel está no ar.

O que é uma VPN IPsec site-to-site no MikroTik?

Uma VPN IPsec site-to-site no MikroTik é um túnel criptografado permanente entre dois roteadores que une duas LANs separadas em uma única rede roteável na camada 3, sem que nenhum dos roteadores exponha uma porta de gerenciamento à internet pública. Diferente das VPNs de acesso de cliente, como WireGuard ou OpenVPN — em que um único equipamento do administrador se conecta —, um túnel site-to-site fica sempre ativo e liga sub-rede a sub-rede: todo host atrás do Roteador A alcança automaticamente todo host permitido atrás do Roteador B. O IPsec é a ferramenta certa aqui porque é um padrão aberto suportado por praticamente todo fabricante de firewall e roteador, roda no kernel do RouterOS com boa vazão e, no MikroTik, já vem embutido, sem pacote extra para instalar.

O túnel é construído em duas negociações. A Fase 1 (IKE) autentica os dois roteadores entre si e estabelece um canal seguro; a Fase 2 (IPsec) negocia as chaves que de fato criptografam o seu tráfego de dados. Com as duas fases batendo nas duas pontas, o túnel sobe; basta um algoritmo divergente para ele falhar silenciosamente — por isso os passos abaixo mantêm os dois lados simétricos.

Antes de começar

Você precisa de dois roteadores MikroTik com RouterOS v7, cada um com um IP público ou um hostname DDNS funcionando, e de duas sub-redes LAN sem sobreposição. Este guia usa 192.168.10.0/24 no Site A e 192.168.20.0/24 no Site B. Se os dois sites usarem 192.168.88.0/24, o roteamento é impossível — reendereçe um dos lados antes. Como o IPsec é muito sensível a diferença de relógio, habilite o NTP nos dois roteadores antes de começar; se as pontas ficarem dessincronizadas, as security associations expiram e o túnel cai o tempo todo.

Cuidar desse pré-requisito em mais do que um punhado de sites já vira trabalho braçal. Quando você opera uma frota, o MKController dá um único console para conferir a versão do RouterOS e a fonte de relógio de cada roteador antes de virar um túnel, para você não ter que logar em cada equipamento só para confirmar que ele está pronto.

Passo 1: Crie o profile e o peer IKE

No Site A, defina o profile da Fase 1 e aponte um peer para o endereço público do Site B:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d

/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
    profile=to-siteB exchange-mode=ike2

dh-group=modp2048 é o Diffie-Hellman Group 14 — um padrão moderno e sólido. exchange-mode=ike2 seleciona o IKEv2, mais rápido e mais robusto que o antigo modo main/IKEv1. As duas pontas precisam usar os mesmos valores de profile e o mesmo exchange mode.

Passo 2: Adicione a identity (chave pré-compartilhada)

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="<long-random-shared-secret>"

Use um segredo longo e aleatório e guarde-o como você guardaria uma chave SSH — não em mensagem de chat. O mesmo segredo vai nos dois roteadores.

Passo 3: Defina o proposal da Fase 2

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=modp2048

O Perfect Forward Secrecy (pfs-group) faz cada rechaveamento usar material de chave novo, então uma chave comprometida nunca expõe o tráfego passado. Assim como na Fase 1, os algoritmos precisam ser iguais nas duas pontas.

Passo 4: Crie a policy do túnel

A policy diz ao RouterOS qual tráfego criptografar — da LAN local para a LAN remota:

/ip ipsec policy add peer=siteB tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    proposal=to-siteB action=encrypt

tunnel=yes é o que torna isso site-to-site em vez de host-to-host: os pacotes originais são encapsulados inteiros, então as duas LANs conversam de forma transparente.

Passo 5: Adicione a regra de bypass de NAT (o passo que todo mundo esquece)

É aqui que a maioria das primeiras tentativas quebra. Seu roteador já tem uma regra de masquerade que reescreve o endereço de origem do tráfego de saída da LAN. Se ela agir antes do IPsec, a ponta remota recebe pacotes cuja origem não casa mais com a policy e os descarta. Adicione uma regra de accept acima do masquerade para que o tráfego destinado ao túnel pule o NAT:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 coloca a regra bem no topo da chain srcnat, o que é obrigatório — uma regra de bypass depois do masquerade não faz nada.

Passo 6: Libere o firewall e verifique

Libere as portas de IKE e NAT-T mais o protocolo ESP na chain input para que o túnel consiga estabelecer, sobretudo se algum dos sites estiver atrás de outro equipamento com NAT:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

Depois confirme que o túnel subiu:

/ip ipsec active-peers print
/ip ipsec policy print

Um túnel saudável mostra um peer ativo e uma policy cujo ph2-state está established. Um ping rápido de um host de uma LAN para um host da outra comprova a conectividade fim a fim.

Espelhe a configuração no Site B

Repita todos os passos no Site B com os endereços invertidos: o peer aponta para o IP público do Site A, e a policy e o bypass de NAT usam src-address=192.168.20.0/24 e dst-address=192.168.10.0/24. O profile, o proposal, o segredo da identity e o modo IKEv2 continuam idênticos. Quando os dois lados batem, a Fase 1 e a Fase 2 se completam e o túnel sobe.

Dicas de segurança e operação

Mantenha o RouterOS atualizado — versões recentes trouxeram correções que mexem na verificação de certificado de peer em IPsec/IKEv2, então um túnel que funcionava no trimestre passado merece um novo teste depois de cada atualização. Prefira IKEv2 com PFS aos padrões antigos do IKEv1. Sempre que possível, migre da chave compartilhada para autenticação por certificado conforme o número de túneis cresce, porque uma única chave pré-compartilhada vazada afeta todos os sites que a compartilham. E registre o estado do túnel em algum lugar que você realmente acompanhe: um link site-to-site morto é invisível até alguém tentar alcançar a LAN do outro lado e não conseguir.

Numa frota, um túnel IPsec que cai em silêncio depois de uma dessincronia de relógio ou de uma oscilação de WAN é exatamente o tipo de falha que o cliente percebe antes de você. O MKController fecha essa lacuna: ele monitora cada roteador por um túnel de saída seguro que não precisa de IP público nem de port forwarding no equipamento, mantém backups de configuração versionados para você comparar e restaurar um bloco IPsec funcional depois de uma edição ruim, e pode abrir um chamado no evento de link-down antes de o telefone tocar. Sobre a configuração do túnel em si, nosso guia de NAT no MikroTik explica a regra de masquerade que você está contornando aqui e, para alcançar um único roteador em vez de unir duas LANs, veja gerenciamento remoto atrás de CGNAT e nosso passo a passo de gerenciamento remoto com WireGuard.

Reúna seus túneis em um só lugar

O IPsec une dois sites de forma limpa, mas um ISP ou MSP em crescimento logo tem dezenas de túneis, chaves e regras de firewall para manter em sincronia — e cada edição manual é uma chance de se trancar para fora de um site remoto. O MKController foi feito exatamente para essa escala: gerenciamento centralizado de frota, acesso remoto seguro sem portas expostas, histórico e backups de configuração e envio de mudanças de firewall e de policy para toda a frota, de modo que um template de túnel é publicado uma vez em vez de ser redigitado roteador por roteador. Operadores que rodam MikroTik em escala usam a plataforma para transformar uma tarde perdida de SSH equipamento por equipamento em alguns cliques por mudança.

Comece seu teste gratuito do MKController