Link redundante com Starlink e MikroTik: como configurar failover para sua empresa

Link redundante com Starlink e MikroTik: como configurar failover para sua empresa

Uma queda de internet pode interromper vendas, emissão de notas, sistemas em nuvem, telefonia, atendimento e acesso remoto. Para empresas que dependem desses serviços, contratar um segundo link é apenas o primeiro passo: também é necessário detectar a falha e transferir o tráfego automaticamente.

Uma solução prática combina a conexão principal, uma Starlink como link redundante e um roteador MikroTik controlando o failover. Quando o link principal deixa de alcançar a internet, o MikroTik direciona a rede para a Starlink. Assim que o serviço volta e se mantém estável, a rota principal pode ser restaurada.

Neste guia, você entenderá como funciona essa arquitetura, quais equipamentos e cuidados ela exige e verá um exemplo de configuração para RouterOS. O exemplo deve ser adaptado ao endereçamento, às interfaces e às regras de segurança de cada ambiente.

O que é um link redundante de internet?

Link redundante é uma segunda conexão disponível para assumir a operação quando a principal falha. O objetivo não é apenas aumentar velocidade, mas reduzir o risco de a empresa ficar completamente offline por causa de um único fornecedor ou meio físico.

Em uma instalação comum:

  • o link de fibra, cabo ou rádio permanece como conexão principal;
  • a Starlink funciona como conexão de contingência;
  • o MikroTik monitora a conectividade dos dois links;
  • as estações continuam usando a mesma rede local;
  • a troca ocorre no roteador, sem reconfigurar cada computador.

A topologia básica fica assim:

Internet principal ---------\
                             > MikroTik > Switch/Wi-Fi > Usuários e sistemas
Starlink -------------------/

Essa arquitetura é chamada de failover WAN. Ela é diferente de balanceamento de carga: no failover, um link é preferido e o outro fica pronto para assumir. No balanceamento, os dois podem transportar conexões ao mesmo tempo, o que exige regras adicionais e nem sempre é adequado para bancos, VPNs, telefonia e aplicações sensíveis à mudança de IP.

Por que usar Starlink como link de backup?

A Starlink utiliza uma infraestrutura diferente dos provedores terrestres. Essa diversidade é valiosa quando a fibra principal e o link reserva tradicional poderiam compartilhar postes, dutos, central, energia ou rota de transporte.

Entre os benefícios estão:

  • cobertura em locais com poucas opções de operadora;
  • implantação sem depender da chegada de fibra ao imóvel;
  • meio físico diferente do link terrestre;
  • capacidade suficiente para manter serviços prioritários durante uma contingência;
  • possibilidade de uso em filiais, áreas rurais, obras e operações temporárias.

Ainda assim, a Starlink não elimina todos os riscos. A antena precisa de visão desobstruída do céu, cabeamento bem instalado, energia protegida e fixação adequada. Chuva intensa, obstruções, danos no cabo ou falhas elétricas podem afetar o serviço. Por isso, redundância deve incluir energia, equipamentos e monitoramento, não apenas dois contratos de internet.

O papel do MikroTik no failover

O MikroTik recebe os dois links em interfaces WAN separadas e decide qual rota padrão deve ser usada. Essa decisão normalmente considera três elementos:

  1. distância da rota: a menor distância tem preferência;
  2. teste de conectividade: o roteador verifica se um destino externo continua acessível;
  3. NAT por saída: cada conexão é traduzida pelo endereço do link utilizado.

Se a rota principal tiver distância 1 e a Starlink distância 2, o RouterOS usa a primeira enquanto ela estiver ativa. Quando o monitoramento considera o caminho indisponível, a rota de backup assume.

O mecanismo precisa testar algo além do modem. Se o MikroTik apenas verificar o gateway local, poderá considerar o link saudável mesmo quando a operadora perdeu acesso à internet. Para uma detecção mais confiável, a documentação oficial da MikroTik sobre failover WAN recomenda rotas recursivas com destinos externos de monitoramento.

Equipamentos e pré-requisitos

Antes de configurar, confirme:

  • MikroTik com pelo menos duas interfaces Ethernet livres para WAN;
  • RouterOS atualizado para uma versão estável e compatível com o equipamento;
  • link principal funcionando em modo roteado, bridge ou conforme o projeto;
  • Starlink com saída Ethernet compatível com a geração do kit;
  • endereçamento das duas WANs sem conflito com a LAN;
  • switch, pontos de acesso e demais equipamentos conectados à LAN do MikroTik;
  • nobreak dimensionado para MikroTik, equipamento da operadora, Starlink e switch;
  • backup da configuração atual antes de qualquer alteração.

Também verifique a capacidade do roteador. Modelos de entrada podem limitar throughput quando existem muitas regras de firewall, filas, VPNs ou inspeção de tráfego. A escolha precisa considerar velocidade dos links, quantidade de usuários e recursos habilitados.

Como conectar Starlink e link principal ao MikroTik

Um desenho simples pode usar:

  • ether1 para o link principal;
  • ether2 para a Starlink;
  • bridge-lan para a rede interna.

Os nomes são apenas exemplos. Em produção, nomes descritivos como WAN-FIBRA e WAN-STARLINK facilitam suporte e reduzem erros.

Quando o roteador da Starlink permanece ativo, o MikroTik recebe um endereço privado por DHCP e existe duplo NAT. Para navegação e contingência, isso costuma funcionar. Quando o projeto exige maior controle, avalie o modo bypass disponível para o modelo do equipamento, sabendo que o comportamento e a forma de reversão variam conforme a geração.

Evite usar a mesma sub-rede na LAN da empresa e em um modem. Se a rede interna usa 192.168.1.0/24 e a Starlink também entrega essa faixa, por exemplo, haverá conflito de roteamento. Altere a LAN corporativa ou a rede administrável do equipamento conforme o projeto.

Configuração simples: prioridades diferentes por DHCP

Quando ambos os links entregam configuração por DHCP, o ponto de partida pode ser definir distâncias diferentes nas rotas recebidas:

/ip/dhcp-client
add interface=ether1 add-default-route=yes default-route-distance=1 disabled=no comment="WAN principal"
add interface=ether2 add-default-route=yes default-route-distance=2 disabled=no comment="WAN Starlink"

Depois, o tráfego da LAN precisa de NAT nas duas saídas:

/ip/firewall/nat
add chain=srcnat action=masquerade out-interface=ether1 comment="NAT WAN principal"
add chain=srcnat action=masquerade out-interface=ether2 comment="NAT WAN Starlink"

Essa abordagem resolve cenários básicos, mas pode detectar apenas perda do endereço, da interface ou do gateway. Se o modem continuar respondendo enquanto a internet da operadora está indisponível, a troca pode não acontecer. Para operações importantes, prefira monitoramento de destinos externos.

Antes de adicionar regras, revise a configuração existente. Muitos ambientes já possuem lista de interfaces WAN e uma regra genérica de masquerade; duplicar NAT pode dificultar diagnóstico.

Configuração mais confiável com rotas recursivas

No failover recursivo, cada link recebe rotas específicas para endereços externos estáveis. A rota padrão usa esses endereços como próximo salto lógico e o RouterOS testa sua disponibilidade com check-gateway=ping.

O exemplo abaixo usa dois destinos por link para reduzir a chance de uma indisponibilidade isolada gerar troca indevida:

/ip/route
add dst-address=1.1.1.1/32 gateway=<GATEWAY_WAN_PRINCIPAL> scope=10 comment="Probe 1 WAN principal"
add dst-address=1.0.0.1/32 gateway=<GATEWAY_WAN_PRINCIPAL> scope=10 comment="Probe 2 WAN principal"

add dst-address=8.8.8.8/32 gateway=<GATEWAY_STARLINK> scope=10 comment="Probe 1 Starlink"
add dst-address=8.8.4.4/32 gateway=<GATEWAY_STARLINK> scope=10 comment="Probe 2 Starlink"

add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=11 check-gateway=ping comment="Principal via probe 1"
add dst-address=0.0.0.0/0 gateway=1.0.0.1 distance=1 target-scope=11 check-gateway=ping comment="Principal via probe 2"

add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=2 target-scope=11 check-gateway=ping comment="Starlink via probe 1"
add dst-address=0.0.0.0/0 gateway=8.8.4.4 distance=2 target-scope=11 check-gateway=ping comment="Starlink via probe 2"

Substitua os campos entre < > pelos gateways reais. Não cole o exemplo diretamente em produção. Se uma WAN recebe gateway dinâmico por DHCP, a solução precisa atualizar as rotas quando a concessão mudar, normalmente com configuração ou automação específica para o ambiente.

Os destinos de teste também devem aceitar ICMP e permanecer acessíveis. Usar dois provedores de destino diferentes reduz falsos positivos, mas o comportamento precisa ser validado. Em redes mais críticas, scripts, Netwatch, múltiplas sondas e ferramentas externas podem controlar tempo de queda, estabilidade e retorno.

Failback: quando voltar ao link principal?

Failover é a ida para o backup. Failback é o retorno ao link principal. Se o link oscila, retornar imediatamente a cada resposta pode criar alternância constante e derrubar sessões repetidas vezes.

Uma política mais madura exige que a conexão principal permaneça estável por determinado período antes de reassumir. O tempo ideal depende da operação. Telefonia, VPN, ERP e sessões bancárias sentem a mudança porque o endereço IP público de saída muda.

Mesmo com troca automática, conexões abertas podem cair e precisar ser refeitas. O failover reduz a indisponibilidade, mas não garante continuidade transparente de toda sessão. Aplicações críticas devem ser testadas individualmente.

Cuidados com VPN, acesso externo e CGNAT

Conexões Starlink podem operar atrás de CGNAT, conforme plano e disponibilidade. Nesse cenário, publicar serviços diretamente por encaminhamento de porta pode não funcionar como em um link com IPv4 público.

Para acesso remoto e integração entre unidades, alternativas mais robustas incluem:

  • VPN iniciada de dentro da empresa para um endpoint com IP público;
  • túnel para um servidor em nuvem;
  • solução de rede sobreposta com autenticação forte;
  • IPv6, quando suportado e corretamente protegido;
  • plano ou recurso que atenda à necessidade de endereço público.

Também confirme como a VPN se comporta após mudar de link. Túneis devem detectar perda, renegociar e restaurar rotas sem depender de intervenção manual.

Como priorizar sistemas durante a contingência

O link reserva pode ter capacidade ou comportamento diferente do principal. Durante a falha, toda a empresa tentará usar a Starlink ao mesmo tempo. Atualizações, streaming, sincronizações e backups podem competir com ERP, telefonia e atendimento.

Use filas e políticas de qualidade de serviço para priorizar o que mantém a operação:

  • ERP e sistemas de vendas;
  • telefonia e videoconferência essencial;
  • VPN entre unidades;
  • emissão fiscal e serviços bancários;
  • e-mail, atendimento e ferramentas de colaboração;
  • monitoramento e segurança.

Rotinas pesadas de backup, atualização e transferência podem ser limitadas ou suspensas enquanto o link secundário estiver ativo. A política precisa ser testada antes da emergência.

Como testar o failover corretamente

Não considere o projeto concluído apenas porque as duas rotas aparecem no MikroTik. Faça testes controlados:

  1. confirme navegação e resolução DNS pelo link principal;
  2. registre IP público, latência e rotas ativas;
  3. simule falha desconectando a WAN principal;
  4. meça quanto tempo a Starlink leva para assumir;
  5. teste ERP, VPN, telefonia, e-mail e aplicações essenciais;
  6. reconecte o link principal e observe o failback;
  7. simule falha da operadora mantendo o modem ligado, quando possível;
  8. confirme alertas, logs e documentação do evento.

Repita o teste periodicamente. Um backup que funcionou na instalação pode falhar meses depois por mudança de cabo, senha, firmware, regra de firewall, contrato ou posicionamento da antena.

Erros comuns em projetos com dois links

Os problemas mais frequentes incluem:

  • contratar dois links que usam a mesma infraestrutura física;
  • monitorar apenas o gateway do modem;
  • não configurar NAT para a segunda WAN;
  • deixar redes dos modems em conflito com a LAN;
  • esquecer DNS, VPN, telefonia e regras de firewall;
  • instalar Starlink com obstruções no campo de visão;
  • não proteger equipamentos com nobreak;
  • confundir failover com soma de velocidade;
  • não controlar tráfego durante a contingência;
  • nunca testar a troca em horário planejado;
  • alterar o MikroTik sem backup e documentação.

Outro erro é expor a administração do roteador à internet. Restrinja WinBox, SSH e interface web a redes e endereços autorizados, mantenha o RouterOS atualizado e use credenciais individuais fortes.

Vale a pena usar Starlink e MikroTik na empresa?

Sim, especialmente quando a empresa depende de serviços online e quer um meio de contingência diferente da fibra principal. A combinação oferece boa flexibilidade, mas o resultado depende do projeto: antena bem posicionada, roteador dimensionado, rotas corretas, firewall revisado, energia protegida e testes recorrentes.

O ponto central é simples: ter dois links não garante redundância por si só. A continuidade nasce da capacidade de detectar a falha certa, trocar de rota, manter sistemas prioritários e avisar a equipe técnica.

Para uma visão mais ampla sobre prevenção e tempo de atendimento, veja também nosso guia sobre SLA de suporte de TI.

Sua empresa precisa implantar Starlink, MikroTik, failover ou monitoramento de internet? Fale com a Mira Sistemas. Avaliamos links, rede, equipamentos, segurança e serviços críticos para criar uma contingência adequada à operação.

Leia também