Redirecione portas no MikroTik com dst-nat, publique uma VM com NAT 1:1 no CHR e configure hairpin NAT para acessar pelo IP público de dentro da rede.

Para que serve

Quando um serviço fica numa máquina com IP privado (um site numa VM atrás do CHR, um sistema no servidor do escritório), é preciso dizer ao roteador para encaminhar as conexões que chegam no IP público até essa máquina. Este artigo mostra como redirecionar portas no MikroTik com dst-nat no RouterOS 7, como dar um IP público inteiro a uma VM (NAT 1:1) num CHR do datacenter e como resolver o problema clássico de "de fora funciona, de dentro não", com o hairpin NAT.

Não publique portas de administração. RDP (3389), SSH, bancos de dados (3306, 5432, 1433), SMB e painéis administrativos não devem ser redirecionados para a internet. Para esses, use VPN (artigo de WireGuard no RouterOS 7). Veja também o artigo «Portas abertas no servidor: quais nunca devem ficar expostas na internet (e como liberar só para o seu IP)» na categoria Firewall.

Pré-requisitos

  • Firewall base aplicado (artigo «Firewall do MikroTik: regras base de filter e raw comentadas (RouterOS 7)»). A regra de forward com connection-nat-state=!dstnat já permite automaticamente o que for redirecionado.
  • Exemplo no datacenter: CHR com WAN ether1 em 203.0.113.19 e IP extra 203.0.113.20 do bloco /28; VMs em 10.10.10.0/24 na ether2. Servidor web em 10.10.10.30.
  • Safe Mode ligado ao mexer em NAT e firewall.

Passo 1: NAT de saída (srcnat)

Para as máquinas internas navegarem, o roteador troca o IP de origem pelo público:

# link com IP fixo (caso do CHR no datacenter): src-nat com endereço definido
/ip firewall nat add chain=srcnat action=src-nat to-addresses=203.0.113.19 out-interface=ether1 comment="saida padrao"

# link com IP dinamico (PPPoE/DHCP no escritorio): masquerade
/ip firewall nat add chain=srcnat action=masquerade out-interface-list=WAN comment="saida padrao"

O masquerade descobre o IP sozinho e limpa as conexões quando o IP muda; com IP fixo, o src-nat é mais previsível.

Passo 2: redirecionar portas no MikroTik (dst-nat)

/ip firewall nat
add chain=dstnat action=dst-nat protocol=tcp dst-address=203.0.113.19 dst-port=80,443 \
    to-addresses=10.10.10.30 comment="site na VM web"
  • Use dst-address (o IP público) em vez de in-interface quando o IP é fixo; isso facilita o hairpin NAT mais adiante. Com IP dinâmico, use in-interface-list=WAN.
  • Para mudar a porta (externa 8443 para interna 443): dst-port=8443 to-ports=443.
  • Para restringir quem pode acessar (por exemplo, um sistema só para o IP do escritório), adicione src-address=198.51.100.2 ou src-address-list=.

Na VM, o gateway precisa ser o próprio MikroTik (10.10.10.1); caso contrário, a resposta sai por outro caminho e a conexão não fecha.

Passo 3: NAT 1:1 para dar um IP público exclusivo a uma VM

No CHR do datacenter, você pode associar um IP do bloco a uma VM inteira. Primeiro o CHR precisa "possuir" o IP extra na WAN:

/ip address add address=203.0.113.20/28 interface=ether1 comment="IP da VM de e-mail"
/ip firewall nat
add chain=dstnat action=dst-nat dst-address=203.0.113.20 to-addresses=10.10.10.31 comment="1:1 entrada"
add chain=srcnat action=src-nat src-address=10.10.10.31 out-interface=ether1 to-addresses=203.0.113.20 \
    place-before=0 comment="1:1 saida"

A regra de saída vem antes da saída padrão (place-before=0), para que a VM saia com o IP dela, e não com o do CHR. Isso é importante, por exemplo, para servidores de e-mail, cujo IP de saída precisa ter DNS reverso (veja o artigo sobre PTR na categoria de rede). Mesmo com 1:1 de entrada, a filtragem continua valendo: libere no forward somente as portas que a VM precisa:

/ip firewall filter
add chain=forward action=accept dst-address=10.10.10.31 protocol=tcp dst-port=25,465,587,993 \
    connection-nat-state=dstnat place-before=[find comment="FWD: internet so entra se houver redirecionamento de porta"]
add chain=forward action=drop dst-address=10.10.10.31 in-interface-list=WAN connection-state=new \
    place-before=[find comment="FWD: internet so entra se houver redirecionamento de porta"]

Passo 4: hairpin NAT (acessar pelo IP público de dentro da rede)

O problema: uma VM em 10.10.10.40 acessa https://203.0.113.19 (ou o domínio do site). O dst-nat leva a conexão para 10.10.10.30, que vê a origem 10.10.10.40, na mesma rede, e responde diretamente, sem passar pelo roteador. A VM de origem recebe a resposta de um IP que ela não chamou e descarta. A solução é também trocar a origem dessas conexões:

/ip firewall nat
add chain=srcnat action=masquerade src-address=10.10.10.0/24 dst-address=10.10.10.0/24 \
    connection-nat-state=dstnat place-before=0 comment="hairpin NAT"

Assim, o servidor vê a conexão vindo do roteador e responde por ele. Repare que, por isso, os logs do servidor web mostram o IP do roteador para acessos internos. Para que o dst-nat também se aplique a quem está dentro, ele precisa casar pelo dst-address (como no passo 2), e não por in-interface=ether1.

Com IP dinâmico, troque o dst-address fixo por dst-address-type=local com dst-address=!192.168.10.1 (o IP da LAN do roteador), para pegar o IP público atual sem sequestrar conexões destinadas ao próprio roteador pela LAN.

Alternativa sem hairpin: um DNS interno que resolve o domínio direto para o IP privado (entrada estática no MikroTik: /ip dns static add name=sistema.exemplo.com.br address=10.10.10.30), com os clientes usando o MikroTik como DNS. Evita o NAT duplo e mantém o IP real nos logs.

Como saber se funcionou

  1. /ip firewall nat print stats: o contador da regra de dst-nat sobe a cada acesso externo.
  2. De fora (celular no 4G): o site abre pelo IP público ou domínio.
  3. De dentro: o mesmo endereço também abre, e o contador da regra de hairpin sobe.
  4. /ip firewall connection print where dst-address~"203.0.113.19" mostra as conexões com o endereço traduzido.
  5. Da VM com NAT 1:1, um site que mostra o IP de origem retorna 203.0.113.20.

Problemas comuns

  • Redirecionamento não funciona de fora: a VM não usa o MikroTik como gateway, o firewall da VM bloqueia a porta, ou a regra está com in-interface errado.
  • Funciona de fora, mas não de dentro: falta o hairpin NAT ou o dst-nat usa in-interface.
  • Winbox do roteador parou de abrir pela LAN: um dst-nat com dst-address-type=local sem exceções capturou a porta do próprio roteador. Restrinja a regra.
  • VM com 1:1 sai com o IP do CHR: a regra de src-nat da VM está abaixo da saída padrão.
  • O IP extra não responde: confira se ele foi adicionado em /ip address na WAN e se está livre no bloco (não usado pelo Proxmox ou por outra VM).

Perguntas frequentes

Qual a diferença entre masquerade e src-nat?

Ambos trocam o IP de origem. O masquerade descobre o IP da interface automaticamente (ideal para IP dinâmico); o src-nat usa um endereço fixo que você informa.

Preciso de regra no filter além do dst-nat?

Com o firewall base deste site, não: a regra que aceita conexões com connection-nat-state=dstnat já cobre. Em firewalls diferentes, libere a porta no forward.

Redirecionar portas funciona com CGNAT?

Não. Se o link do escritório recebe IP de CGNAT (100.64.x.x), as conexões de fora não chegam ao seu roteador. Publique o serviço no servidor dedicado ou use a VPN no sentido contrário.

Leitura complementar

Precisa de ajuda?

Se o IP extra do seu bloco /28 não responde no CHR mesmo com a configuração correta, confira de novo a máscara, o gateway e o firewall do Proxmox na placa. A rede não exige registrar o MAC da VM. Se ainda assim não funcionar, abra um ticket informando o IP e o ID da VM.

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

Leia também