Failover Dual-WAN MikroTik para ISPs

Resumo O failover dual-WAN da MikroTik mantém um local online movendo automaticamente o tráfego para um uplink de backup quando o link primário falha. O RouterOS oferece três blocos de construção — roteamento recursivo com check-gateway, Netwatch e NAT por WAN — e a combinação certa depende de quão rápida e quão inteligente sua detecção precisa ser. Para frotas de ISP, o problema mais difícil não é o trecho de configuração, mas confirmar, em centenas de sites remotos atrás de CGNAT, que o failover realmente funcionou. Este guia cobre os dois.

O Que É o Failover Dual-WAN da MikroTik?

O failover dual-WAN da MikroTik é uma configuração do RouterOS que dá a um roteador dois uplinks de internet — um primário e um de backup — e desloca automaticamente o tráfego para o backup quando o primário deixa de passar pacotes, voltando depois quando ele se recupera. Não é o mesmo que balanceamento de carga: o failover mantém um link ocioso como seguro, enquanto o balanceamento distribui o tráfego entre os dois. O objetivo é continuidade, não banda extra, e é por isso que ele é o padrão de redundância para locais que simplesmente não podem ficar fora do ar.

O mecanismo se apoia na seleção de rotas. O RouterOS escolhe a rota padrão ativa pela menor distância administrativa, então você dá ao primário uma distância menor e ao backup uma maior. Todo o projeto então se reduz a uma pergunta: como o roteador decide que o primário está “fora” e rebaixa sua rota? Acerte essa decisão — rápido o suficiente, mas sem nervosismo — e o failover será confiável. Erre e você ou fará a comutação lenta demais ou ficará oscilando entre os links a cada pacote perdido.

Passo 1 — Mapeie as duas WANs antes de tocar em uma rota

Comece anotando o que cada uplink realmente é. Um primário de fibra fixa ou PPPoE com gateway estático ou atribuído por PPP se comporta de forma diferente de um backup Starlink ou LTE que fica atrás de Carrier-Grade NAT e lhe entrega um endereço dinâmico. Isso importa porque o roteamento recursivo só funciona com gateways de IP estáveis, não com tipos de interface dinâmicos como PPPoE ou DHCP, em que o endereço pode mudar (Documentação MikroTik — Failover (WAN Backup)). Decida qual link é primário, qual é backup e se algum deles muda de IP ao reconectar — esse único fato dita qual método de detecção você pode usar.

Passo 2 — Adicione rotas padrão recursivas com check-gateway

A abordagem clássica usa roteamento recursivo: em vez de apontar a rota padrão diretamente para um próximo salto, você a aponta para um alvo de sondagem (por exemplo, um resolvedor público conhecido) e adiciona uma rota estática dizendo ao RouterOS para alcançar esse alvo apenas através de um gateway WAN específico. Você então cria duas rotas padrão resolvidas recursivamente sobre esses alvos — a primária com distância menor e check-gateway=ping habilitado, e a de backup com distância maior (Scoop — Basic ISP Failover with MikroTik).

O comportamento a planejar é o tempo. O check-gateway desativa uma rota após duas verificações consecutivas com falha, e as verificações ocorrem a cada 10 segundos, então a comutação real fica em torno de 20 a 30 segundos — e ele não reage à perda intermitente de pacotes, apenas a um gateway totalmente morto (Documentação MikroTik — Failover (WAN Backup)). Para muitos sites de clientes de ISP isso é aceitável. Para terminais de voz ou pagamento muitas vezes não é, e é aí que entra o Passo 4.

Passo 3 — Configure o NAT para os dois uplinks

Um roteador dual-WAN precisa de uma regra de masquerade (ou src-nat) separada por interface WAN para que o link ativo traduza corretamente o tráfego de saída; uma única regra ligada a uma interface quebrará silenciosamente a conectividade no momento em que o failover mover o tráfego para o outro link. Adicione uma regra de masquerade na cadeia srcnat para a out-interface primária e uma segunda para o backup. Se você publica algum serviço de entrada, lembre-se de que regras dst-nat ligadas ao endereço do primário param de funcionar quando esse link — e seu IP público — desaparece. Essa fragilidade de entrada é a mesma armadilha arquitetural abordada em nosso caso de mudanças de IP no Starlink, e é por isso que o acesso ancorado na saída escala melhor que o encaminhamento de portas. Para os fundamentos de NAT, veja nosso guia de configuração de NAT no MikroTik.

Passo 4 — Use o Netwatch quando precisar de detecção mais rápida ou mais inteligente

Quando 20–30 segundos é lento demais ou você precisa agir sobre links degradados-mas-vivos, o Netwatch é a ferramenta mais flexível. No RouterOS v7, o Netwatch ganhou um parâmetro type que pode sondar com icmp, tcp-conn, http-get, https-get ou simple, e você pode definir seu próprio intervalo de verificação em vez de conviver com a cadência fixa do check-gateway (Documentação MikroTik — Failover (WAN Backup)). Cada host tem um script up e um down, então você pode desabilitar a rota padrão primária, disparar um alerta ou registrar o evento na transição.

Muitos operadores combinam os dois: o roteamento recursivo cuida da morte limpa do link, enquanto o Netwatch cobre os casos mais confusos e envia notificações. Uma longa discussão na comunidade debate exatamente esse trade-off e vale a leitura antes de você padronizar um método em toda a frota (Fórum MikroTik — netwatch instead of recursive routing). Qualquer que seja sua escolha, mantenha a configuração idêntica em todos os sites — uma frota de scripts de failover sob medida é, por si só, uma queda esperando para acontecer.

Passo 5 — Verifique o failover em cada site remoto

Aqui está a parte que os tutoriais de configuração pulam. Adicionar as rotas em um roteador de bancada é fácil; provar que o failover funciona em centenas de CPEs implantados é o verdadeiro problema do ISP — e fica mais difícil quando o link de backup é Starlink ou LTE atrás de CGNAT, porque o dispositivo muitas vezes não tem um IP público acessível para gerenciá-lo depois da comutação. Se você só consegue confirmar o failover esperando um cliente ligar, você não tem failover de verdade; tem um script que você torce para que rode.

É aqui que o gerenciamento centralizado muda a economia. O MKController mantém cada roteador acessível por meio de um túnel de saída autenticado, então você pode confirmar que o caminho de backup está carregando tráfego, observar a transição de failover no monitoramento e enviar uma configuração corrigida — sem depender de um IP público que pode não existir no link de backup. Combine isso com telemetria: nossos guias sobre monitorar o MikroTik remotamente com Zabbix e monitoramento SNMP para MikroTik mostram como alertar sobre o próprio evento de failover, para que uma troca silenciosa para o link de backup caro nunca passe despercebida.

Dicas

• Mantenha a sonda check-gateway do link de backup apontada para um alvo que você alcança através desse link, não pelo primário, ou seu teste não terá sentido.
• Marque as transições de failover no seu monitoramento para que um site rodando há dias em seu uplink de backup gere um chamado — failover que ninguém percebe é um custo recorrente, não um salvamento.
• Teste o cabo de verdade, não apenas a rota: puxe o conector do primário e cronometre a comutação real.

Traga o failover para um único plano de controle

O failover dual-WAN em um único MikroTik é um problema resolvido. Fazê-lo de forma confiável em toda uma frota — com configuração consistente e a capacidade de provar que o backup funciona em um roteador que você não alcança por IP público — é onde a maioria dos operadores perde dinheiro. O gerenciamento centralizado, ancorado na saída, fecha essa lacuna.

Comece seu teste gratuito do MKController