Configurando roteador dual wan load balance na prática
O conceito é simples: você conecta dois links de internet ao mesmo roteador e ele distribui o tráfego entre os dois. Na teoria. Na prática, existem coisas que ninguém conta nos manuais porque os fabricantes assumem que você vai usar apenas para browsing e e-mail. Eu configurei esse tipo de sistema para uma clínica médica que tinha um link de 100 Mbps e outro de 50 Mbps. A espera era óbvia: ganhar 150 Mbps de banda agregada. O resultado real foi perto de 110 Mbps úteis. A diferença vem da sobrecarga de manter duas conexões ativas, da latência assimétrica e do fato de que packets saindo por portas diferentes podem chegar em ordens diferentes, o que Quebra a maioria dos aplicativos.
roteador dual wan load balance: o que funciona e o que quebra
Existem basicamente dois modelos de distribuição. O primeiro é o balanceamento por hash de IP de origem e destino. O roteador decide para qual WAN cada fluxo vai com base numa tabela de hash. É rápido, consome poucos recursos e funciona bem para navegação geral. O problema é que um único usuário com múltiplas conexões simultâneas — o que é comum com downloads modernos, torrents e até o Chrome com dezenas de abas — pode acabar usando apenas uma das WANs enquanto a outra fica ociosa. O segundo modelo é o balanceamento por source, que pesha a carga com base na origem do pacote. Esse é o que a maioria dos roteadores enterprise usa. Você consegue configurar pesos diferentes para cada link, então num cenário de 100 Mbps e 50 Mbps você atribui peso 2 para o link maior e peso 1 para o menor. O roteador envia dois pacotes para cada um que vai para o link pequeno. Parece lógico. Funciona até alguém fazer um upload grande.
Aqui vai uma coisa que eu aprendi da hard way: load balance não melhora velocidade de upload da forma como as pessoas imaginam. Se você tem dois links de 10/100 (download/upload simétrico), o upload aggregate funciona razoavelmente bem. Mas se um link é 100/20 e o outro é 50/10, o roteador vai tentar equilibrar o download e o upload vai ficar estranho. Alguns pacotes sobem pelo link rápido, outros pelo lento. Aplicativos que mantêm conexões persistentes — VPNs, VoIP, sessões SSH longas — simplesmente odeiam isso. A resolução mais prática que eu encontrei foi configurar sticky sessions com um timeout de 300 segundos. Depois desse tempo, o hash é recalculado. Reduz pela metade as quebras de sessão em comparação com o padrão de 60 segundos.
Passo a passo para configurar
Vamos começar pelo básico. Você precisa de dois roteadores ou de um único equipamento que suporte dual WAN. Roteadores domésticos como os padrão operadora geralmente não suportam. Você vai precisar de um equipamento com software customizado ou um router enterprise. Opções de firmware e equipamentos:
OpenWrt é a escolha mais comum para quem quer fazer isso sem gastar uma fortuna. Ele roda em hardware Mikrotik, em placas BCM-based e em várias plataformas x86. A interface é via linha de comando, o que assusta gente que não tem familiaridade, mas a comunidade tem scripts prontos para configurar load balance básico em poucos minutos. Mikrotik RouterOS tem uma implementação robusta chamada pcc (Per Connection Classifier). Diferente de muitos sistemas que usam balanceamento round-robin cego, o PCC divide o tráfego baseando-se em pares de IP de origem e destino com um parâmetro que você define. O comando básico é algo como:
ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1,192.168.2.1 routing-table=main distance=1 E depois o classificador:
ip route add dst-address=0.0.0.0/0 gateway=192.168.1.1 distance=1 ip route add dst-address=0.0.0.0/0 gateway=192.168.2.1 distance=1
👉 Clique no botão abaixo para saber mais sobre o assunto!
ip address add address=192.168.1.1/24 interface=ether1 ip address add address=192.168.2.1/24 interface=ether2
ip route rule add dst-address=0.0.0.0/0 src-address=0.0.0.0/0 action=lookup table=main Não vou entrar em cada linha aqui porque depende da sua topologia de rede. O importante é entender que o PCC usa um divisor. Se você quer dividir 70% do tráfego para uma WAN e 30% para outra, o divisor precisa ser calculado com base na proporção desejada. Um erro comum é usar divisores iguais quando os links têm velocidades diferentes. Resultado: o link mais rápido fica subutilizado e o mais lento engasga.
Alternativas comerciais: Se você não quer lidar com CLI, existem soluções como o GL.iNet com OpenWrt pré-configurado, que tem interface web e suporta dual WAN out of the box. Equipamentos da TP-Link Omada também oferecem essa funcionalidade em modelos Enterprise. Para cenários corporativos maiores, Ubiquiti EdgeRouter e os equipamentos da Fortinet com SD-WAN fazem balanceamento com monitoramento ativo de saúde dos links.
O problema que ninguém menciona
Configurei um sistema desses para um escritório com 40 usuários. Tinha fibra 200/200 e um link 100/100 de backup. O load balance funcionava perfeitamente para navegação. Até que começamos a usar. Problemas de jitter e latência flutuante apareciam aleatoriamente. Descobrimos que o VoIP estava sendo distribuído entre as duas WANs, e como cada uma tem latência diferente, os pacotes de áudio chegavam dessincronizados. A solução foi usar policy-based routing para enviar todo o tráfego de voz e vídeo para a mesma WAN. No MikroTik, você cria uma regra de firewall que identifica o tráfego por porta (5060-5061 para SIP, o restante para RTP) e encaminha para uma tabela de rota específica que aponta só para um gateway. Isso elimina a dessincronização. Custou cerca de 15 minutos de configuração adicional.
Outro ponto importante: failover automático. O load balance sozinha não resolve nada se um link cai e o roteador continua enviando tráfego para ele. Você precisa de monitoramento ativo. A maioria dos sistemas fareja o gateway ou faz ping para um IP confiável (geralmente 8.8.8.8 ou 1.1.1.1). Se o ping falhar por três tentativas consecutivas, o roteador marca a rota como down e desvia todo o tráfego para a outra WAN. O problema é que o monitoramento baseado em ping pode dar falso positivo. Às vezes o link está funcionando mas o ping para um servidor externo está lento por congestão na ISP. O resultado é o roteador tirando o link da rotação desnecessariamente. Para resolver, eu configuro o intervalo de check a cada 10 segundos com um timeout de 5 segundos, e uso como alvo um IP da própria ISP sempre que possível. Se não tiver, pelo menos use dois alvos diferentes (8.8.8.8 e 1.1.1.1) e considere o link down só se ambos falharem.
Números reais de performance
Em testes com dois links de 100 Mbps simétricos, a banda agregada útil fica em torno de 160 a 170 Mbps, não 200. Perda de 15-20% é normal por causa da sobrecarga do balanceamento. Com links assimétricos como 200/50 e 100/30, a ganho real de download é de cerca de 260 Mbps, mas o upload raramente passa de 65 Mbps porque a maioria dos pacotes de resposta volta pela mesma WAN que recebeu a requisição. Se o seu foco principal é upload pesado — transmissões ao vivo, backups para nuvem, envio de arquivos grandes — load balance dual WAN talvez não valha o custo e a complexidade. Nesse caso, investir em um único link simétrico de maior velocidade é mais simples e performa melhor na prática. Eu já vi clientes gastarem tempo configurando tudo e depois reclamar que o upload não melhorou como esperavam.
O load balance dual WAN brilha em cenários onde você tem múltiplos links de baixa latência e precisa de redundancy combinada com throughput maior para download. Se o seu uso é predominantemente upload, considere SD-WAN com otimização de fluxo em vez de balanceamento simples. A diferença de preço hoje em dia não é tão grande assim, e a experiência do usuário final costuma ser muito superior.
