WireGuard no MikroTik RouterOS 7: acesso remoto para notebooks e celulares, túnel com a VM WireGuard no Proxmox, firewall, rotas e monitoramento.

Para que serve

O WireGuard no MikroTik (nativo desde o RouterOS 7) resolve dois cenários comuns: (1) a equipe acessa a rede do escritório de casa, pelo notebook ou celular, usando o MikroTik como servidor de VPN; (2) o MikroTik do escritório mantém um túnel permanente com a VM WireGuard que roda no Proxmox do seu servidor dedicado, para que todos acessem ERP, banco e RDP das VMs. O passo a passo básico do túnel escritório ↔ servidor, com pfSense e OPNsense, está no artigo «Como configurar VPN site-to-site entre o escritório e o servidor dedicado (WireGuard com MikroTik, pfSense e OPNsense)» da categoria VPN. Aqui vamos além: acesso remoto pelo próprio MikroTik, o que muda quando o lado do servidor é uma VM, regras de firewall, monitoramento e túnel entre dois MikroTik (escritório e CHR).

Pré-requisitos

  • RouterOS 7 atualizado (versões mais novas trazem melhorias no WireGuard, como a geração de configuração para clientes).
  • Firewall base aplicado (artigo «Firewall do MikroTik: regras base de filter e raw comentadas (RouterOS 7)») e listas WAN/LAN.
  • Faixas que não se sobrepõem. Exemplos deste artigo:
    • LAN do escritório: 192.168.10.0/24.
    • Clientes remotos no MikroTik: 10.20.0.0/24 (roteador em 10.20.0.1).
    • Túnel com o servidor: 10.8.0.0/24; VM WireGuard em 10.8.0.1, MikroTik em 10.8.0.100.
    • VMs no Proxmox: 10.10.10.0/24; VM WireGuard com 10.10.10.5 nessa rede e IP público 203.0.113.20.
  • Safe Mode ligado durante alterações de firewall e acesso local ao MikroTik.

Parte 1: WireGuard no MikroTik para acesso remoto (road warrior)

  1. Crie a interface e o endereço:

    /interface wireguard add name=wg-remoto listen-port=13231 mtu=1420
/ip address add address=10.20.0.1/24 interface=wg-remoto
/interface list member add list=LAN interface=wg-remoto

    Colocar o túnel na lista LAN faz as regras do firewall base tratá-lo como rede interna. Se quiser que usuários remotos tenham menos acesso que a LAN, crie uma lista própria (por exemplo VPN) e escreva regras específicas.

  2. Libere a porta na WAN (antes do drop final da input):

    /ip firewall filter add chain=input action=accept protocol=udp dst-port=13231 in-interface-list=WAN \
    place-before=[find comment="IN: descarta o resto"] comment="IN: WireGuard"

  3. Cadastre cada dispositivo como peer. Gere o par de chaves no app WireGuard do notebook (botão "Add empty tunnel") e copie a chave pública:

    /interface wireguard peers
add interface=wg-remoto name=notebook-ana public-key="CHAVE_PUBLICA_DO_NOTEBOOK" \
    allowed-address=10.20.0.2/32 comment="Ana - notebook"

    No peer de um cliente remoto, allowed-address é só o IP dele (/32). Um peer por dispositivo, nunca compartilhado.

  4. Monte a configuração do cliente. Pegue a chave pública do roteador com /interface wireguard print e complete o túnel no app:

    [Interface]
PrivateKey = (gerada pelo app)
Address = 10.20.0.2/32
DNS = 192.168.10.1

[Peer]
PublicKey = CHAVE_PUBLICA_DO_MIKROTIK
Endpoint = IP_OU_NOME_DO_ESCRITORIO:13231
AllowedIPs = 10.20.0.0/24, 192.168.10.0/24, 10.10.10.0/24
PersistentKeepalive = 25

    Esse é um split tunnel: só as redes da empresa passam pela VPN. Incluir 10.10.10.0/24 permite que o usuário remoto alcance também as VMs pelo túnel do escritório (Parte 2). Se o escritório não tem IP fixo, use o DDNS do próprio MikroTik (/ip cloud set ddns-enabled=yes e use o nome exibido em /ip cloud print). Escritórios atrás de CGNAT não conseguem receber conexões; nesse caso, o servidor de acesso remoto deve ser a VM WireGuard do datacenter.

    Nas versões mais recentes do RouterOS 7, o peer aceita client-address, client-dns e client-endpoint, e o comando /interface wireguard peers show-client-config exibe o arquivo pronto e um QR code para o celular. É prático, mas o método manual acima funciona em qualquer versão.

Parte 2: túnel do MikroTik com a VM WireGuard no Proxmox

No padrão adotado pela E-Consulters, o WireGuard do lado do servidor roda numa VM dedicada, e não no host Proxmox. Configure o MikroTik como no artigo de VPN site-to-site (interface wg-datacenter, peer com endpoint-address=203.0.113.20, allowed-address=10.8.0.0/24,10.10.10.0/24 e persistent-keepalive=25s). Os pontos abaixo são os que mais causam problema e não aparecem no passo a passo básico.

2.1 A volta do tráfego dentro do Proxmox

Como a VM WireGuard não é o gateway das outras VMs, um servidor em 10.10.10.30 recebe o pacote do escritório e tenta responder pelo gateway padrão dele, que não conhece 192.168.10.0/24. Escolha uma das soluções:

  • Rota estática no gateway das VMs (OPNsense, CHR ou o próprio host, conforme o seu desenho): 192.168.10.0/24 e 10.8.0.0/24 via 10.10.10.5. Mantém o IP real do usuário nos logs.
  • Masquerade na VM WireGuard para o tráfego que sai para 10.10.10.0/24: as VMs veem tudo vindo de 10.10.10.5. Funciona sem mexer em rotas, mas perde-se o IP de origem.

Na VM WireGuard (Debian), lembre-se do net.ipv4.ip_forward=1 e, no peer do escritório, AllowedIPs = 10.8.0.100/32, 192.168.10.0/24. Se o firewall do Proxmox estiver ativo na placa da VM, libere 51820/udp nela.

2.2 Firewall do MikroTik para o túnel

Em vez de regras por endereço, crie uma lista de interfaces para os túneis e use-a no forward:

/interface list add name=TUNEIS
/interface list member add list=TUNEIS interface=wg-datacenter
/ip firewall filter
add chain=forward action=accept in-interface-list=LAN out-interface-list=TUNEIS comment="LAN -> datacenter" \
    place-before=[find comment="FWD: descarta o resto"]
add chain=forward action=accept in-interface-list=TUNEIS out-interface-list=LAN dst-address=192.168.10.0/24 \
    protocol=icmp comment="datacenter -> LAN apenas ping" place-before=[find comment="FWD: descarta o resto"]
/ip firewall nat add chain=srcnat action=accept out-interface-list=TUNEIS place-before=0 comment="sem NAT no tunel"

Assim o escritório inicia conexões para as VMs, mas as VMs só conseguem pingar o escritório. Abra mais portas apenas se houver necessidade real (por exemplo, a VM de backup buscando arquivos de um NAS do escritório).

2.3 Monitorar o túnel com Netwatch

O WireGuard não tem estado de "conectado". Use o Netwatch para registrar no log (ou disparar um e-mail) quando a VM deixar de responder pelo túnel:

/tool netwatch add host=10.8.0.1 interval=30s type=icmp \
    down-script=":log warning \"WG datacenter fora\"" up-script=":log info \"WG datacenter ok\""

2.4 MTU em links PPPoE

Fibra via PPPoE (MTU 1492) é a regra no Brasil. Use mtu=1412 na interface WireGuard ou mantenha o MSS clamp no mangle. Sintoma típico de MTU errado: o ping passa, mas o RDP congela e páginas carregam pela metade.

Parte 3: MikroTik do escritório com um CHR no datacenter

Se você usa um CHR como roteador das VMs (artigo «Como instalar o MikroTik CHR no Proxmox VE (Cloud Hosted Router como roteador das VMs)»), o túnel pode ser feito diretamente entre os dois RouterOS:

# No CHR (datacenter)
/interface wireguard add name=wg-escritorio listen-port=13231
/ip address add address=10.8.1.1/30 interface=wg-escritorio
/interface wireguard peers add interface=wg-escritorio public-key="CHAVE_DO_ESCRITORIO" \
    allowed-address=10.8.1.2/32,192.168.10.0/24
/ip route add dst-address=192.168.10.0/24 gateway=wg-escritorio

# No MikroTik do escritório
/interface wireguard add name=wg-chr listen-port=13232
/ip address add address=10.8.1.2/30 interface=wg-chr
/interface wireguard peers add interface=wg-chr public-key="CHAVE_DO_CHR" endpoint-address=203.0.113.19 \
    endpoint-port=13231 allowed-address=10.8.1.1/32,10.10.10.0/24 persistent-keepalive=25s
/ip route add dst-address=10.10.10.0/24 gateway=wg-chr

Como o CHR é o gateway das VMs, não há problema de rota de volta. Repita as regras de firewall da seção 2.2 nos dois lados.

Como saber se funcionou

  1. /interface wireguard peers print detail mostra last-handshake de poucos segundos e contadores rx/tx subindo.
  2. Do notebook remoto: ping 10.20.0.1, depois ping 192.168.10.1 e o IP de uma VM.
  3. Do escritório: Test-NetConnection 10.10.10.30 -Port 3389 retorna TcpTestSucceeded : True.
  4. /log print where message~"WG" mostra os eventos do Netwatch.

Problemas comuns

  • Sem handshake: porta UDP fechada na input, chave pública trocada ou o escritório está atrás de CGNAT (não recebe conexões).
  • Handshake ok, VM não responde: problema de rota de volta (seção 2.1) ou firewall da VM de destino.
  • Usuário remoto acessa o escritório, mas não as VMs: falta 10.20.0.0/24 no AllowedIPs do peer do escritório na VM WireGuard e na rota de volta do Proxmox.
  • Tudo parou depois de atualizar o RouterOS: confira se o peer ainda tem endpoint-address e se nenhuma regra nova foi parar antes do aceite da porta.

Perguntas frequentes

Qual a porta padrão do WireGuard no MikroTik?

13231/udp. Você pode usar qualquer porta UDP livre; o importante é que ela esteja liberada na input.

Preciso de IP fixo no escritório?

Para o túnel com o datacenter, não: o escritório inicia a conexão. Para receber usuários remotos no MikroTik, é preciso um IP público (fixo ou com DDNS) e não pode haver CGNAT.

WireGuard no MikroTik usa certificado?

Não. Cada lado tem um par de chaves; basta trocar as chaves públicas.

Quantos clientes o MikroTik aguenta?

Depende da CPU do modelo. Para dezenas de usuários simultâneos com tráfego alto, prefira um RouterBOARD com CPU ARM64 ou um CHR.

Leitura complementar

Precisa de ajuda?

Se o túnel não fechar, abra um ticket com a saída de /interface wireguard peers print detail (sem chaves privadas), as faixas de rede usadas e o resultado de wg show na VM WireGuard.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também