Por que a VPN entre matriz e filial fica caindo?
VPN entre matriz e filial caindo raramente é defeito do equipamento. As causas mais comuns são o link de uma das pontas oscilando, endereço público que muda sem aviso, configuração diferente entre os dois lados e sobreposição de faixas de endereços na rede interna.
O sintoma é sempre parecido: o sistema da filial trava por alguns minutos, volta, e ninguém consegue reproduzir. Quando a VPN entre matriz e filial cai várias vezes ao dia, quase sempre existe um padrão — e encontrá-lo é mais barato do que trocar os dois equipamentos para descobrir que o problema era o link.
As causas mais comuns
Em ordem do que encontramos com mais frequência:
- Link oscilando em uma das pontas. A conexão não cai por completo, mas perde pacotes o suficiente para o túnel se desfazer. A ponta com link pior derruba os dois lados.
- Endereço público que muda. Se uma unidade tem endereço dinâmico, cada renovação derruba o túnel até a configuração acompanhar.
- Configuração diferente entre os lados. Tempo de vida da chave, algoritmos e parâmetros precisam combinar; divergência produz queda periódica, quase sempre em intervalo regular.
- Sobreposição de faixas de endereço. Se matriz e filial usam a mesma faixa interna, o tráfego não sabe para onde ir. Costuma aparecer como 'funciona para algumas coisas e para outras não'.
- Roteador da operadora na frente do firewall, em modo que atrapalha o estabelecimento do túnel.
- Energia instável em uma das pontas, derrubando o equipamento por segundos.
- Firmware desatualizado em um dos lados.
O que medir antes de trocar qualquer coisa
Trocar equipamento sem medir costuma reproduzir o problema:
- Registre o HORÁRIO de cada queda por alguns dias. Padrão regular aponta para configuração; padrão irregular aponta para link ou energia.
- Monitore separadamente cada link, fora do túnel, medindo perda de pacote e variação de latência. É isso que revela o link que oscila sem cair.
- Verifique se alguma das pontas tem endereço público dinâmico.
- Compare as configurações dos dois lados, parâmetro a parâmetro.
- Confirme que as faixas de endereço interno das unidades são diferentes.
- Verifique o registro do firewall no momento da queda: ele costuma dizer qual lado encerrou e por quê.
O segundo item é o que mais resolve: link que oscila não aparece em teste de velocidade, só em medição contínua.
Correções, da mais simples à mais estrutural
Na ordem de esforço:
- Alinhar os parâmetros dos dois lados e atualizar o firmware de ambos.
- Resolver o endereço dinâmico: contratar endereço fixo, ou usar um nome que acompanhe a mudança.
- Colocar o roteador da operadora em modo de passagem, deixando o firewall gerenciar a conexão.
- Corrigir a sobreposição de faixas — trabalhoso, porque mexe no endereçamento interno, e definitivo.
- Proteger a energia dos equipamentos de rede nas duas pontas.
- Contratar contingência de link na unidade que oscila, quando a operação não tolera a queda.
Reduzir o impacto quando a queda for inevitável
Nem toda instabilidade é eliminável a custo razoável. Dá para doer menos:
- Colocar na nuvem o que não precisa passar pelo túnel — e-mail e arquivos de escritório são os candidatos naturais.
- Manter na filial uma cópia local do que ela consulta o tempo todo, quando o sistema permitir.
- Configurar reconexão automática com intervalo curto, para que a queda dure segundos em vez de minutos.
- Alertar quando o túnel cair, para que a TI saiba antes da filial ligar.
- Combinar com a operação o que fazer nos minutos sem conexão, em vez de deixar cada um improvisar.
Como isso fica no contrato mensal
Túnel entre unidades precisa de monitoramento nas duas pontas: se ninguém mede o link separadamente, a discussão vira a matriz culpando a filial. No contrato mensal, os dois lados são monitorados, a queda gera alerta com registro, o firmware é mantido em dia e as configurações ficam documentadas. Veja Firewall e VPN gerenciados e os planos de suporte mensal.