Funcionamento básico da VPN site-to-site

Uma VPN site-to-site cria um “corredor” de comunicação protegido entre dois gateways (por exemplo, firewalls ou roteadores) em redes diferentes. Em termos práticos, o gateway A encapsula o tráfego destinado à rede do site B e o envia até o gateway B, que desencapsula e encaminha o tráfego para a rede interna correspondente.

Mesmo quando o túnel “parece” estabelecido, ainda pode haver falhas porque a VPN depende de mais do que criptografia: ela exige que negociação de parâmetros funcione, que haja conectividade IP entre os gateways, que existam rotas (routing) compatíveis para direcionar o tráfego e que regras de firewall permitam o encapsulamento e o tráfego pós-encapsulado.

Problemas comuns na prática

  1. Túnel não estabelece (ou fica instável)
  • Parâmetros incompatíveis entre os gateways (por exemplo, métodos de autenticação, configurações de criptografia, identificadores ou chaves).
  • Alcance/rota entre os gateways incorreto (o tráfego que carrega a VPN não chega).
  • Bloqueio por firewall/NAT que impede o tráfego necessário para a negociação e para o túnel.
  1. Túnel “está de pé”, mas não funciona o tráfego
  • Rotas ausentes ou incorretas: o gateway pode não saber que deve enviar para o túnel o tráfego destinado às redes remotas.
  • Políticas de encaminhamento (ACLs/regras) bloqueando a passagem do tráfego interno.
  • Seletores de tráfego (quais redes/sub-redes entram no túnel) divergentes: o tráfego até tenta atravessar, mas não coincide com o que o túnel está autorizado a transportar.
  1. Conectividade parcial ou intermitente
  • MTU/fragmentação: encapsulamento aumenta tamanho do pacote e pode causar perda quando há caminhos com MTU menor.
  • Conflitos de rotas: em alguns cenários, o tráfego pode sair por uma rota “concorrente” em vez do túnel.
  • Limitações do desenho de rede (topologia) que não foram consideradas no planejamento.
  1. Falhas específicas de endereçamento
  • Overlap de sub-redes (mesmo ranges de IP em ambos os lados) pode tornar a comunicação ambígua, exigindo ajustes no projeto.
  • DNS: a VPN permite tráfego IP, mas a resolução de nomes depende de como o DNS é configurado em cada lado.

Verificações práticas passo a passo

  1. Confirme conectividade entre os gateways Antes de culpar a VPN, verifique se do ponto de vista de IP o gateway A alcança o endereço do gateway B (e vice-versa, quando aplicável). Se não houver caminho de rede, a negociação não vai avançar.

  2. Revise as correspondências de parâmetros de túnel Sem entrar em “receita única”, a ideia é comparar se os dois lados falam a mesma “linguagem”: autenticação/credenciais, configurações de criptografia e identificadores do par. Quando há discrepância, o túnel pode falhar na fase de negociação ou ficar repetindo tentativas.

  3. Valide seleção de tráfego e sub-redes cobertas Verifique se as redes internas que você quer acessar realmente estão incluídas nos critérios do túnel. Um erro comum é incluir “o que parece ser” a rede, mas deixar de fora uma sub-rede específica, ou configurar com ranges diferentes.

  4. Checar rotas no gateway e política de encaminhamento Depois do túnel, pergunte: “Quando alguém no site A tenta acessar X no site B, para onde o gateway encaminha esse tráfego?”

  • Se não existir rota/encaminhamento apontando para o túnel, o tráfego não atravessa.
  • Se existirem regras que negam o tráfego (ACLs/firewall interno), o túnel pode permanecer ativo sem transportar a aplicação.

  1. Use logs e timestamps para identificar a etapa falha Os logs normalmente ajudam a separar “falha na negociação” de “falha na autorização/encaminhamento do tráfego”. Se os logs indicam repetição de negociação, foque na conectividade e parâmetros; se indicam estabelecimento sem tráfego, foque rotas, seletores de tráfego e políticas.

  2. Teste com tráfego simples e medidas consistentes Comece com testes ICMP e acesso a um host específico na rede remota (quando permitido). Se funcionar para um host e não para outro, procure por diferenças de regras, rotas ou coincidência de sub-redes. Em caso de lentidão ou perda, considere MTU/fragmentação como hipótese.

Diferenças, limitações e exceções que mudam o diagnóstico

  • NAT e tradução de endereços: ambientes com NAT podem exigir cuidado extra para que os gateways e firewalls reconheçam o tráfego encapsulado. Quando NAT está presente, falhas de “parece que conecta” podem ser na verdade problemas de mapeamento.
  • Overlap de sub-redes: se ambas as pontas usam os mesmos ranges, mesmo que o túnel estabeleça, o tráfego pode não chegar ao destino correto. Nesses casos, o problema pode ser de endereçamento e encaminhamento, não de criptografia.
  • Nem todo tráfego vai “automagicamente” pelo túnel: a VPN costuma ser definida por redes específicas. Tráfego para destinos fora dos critérios não será transportado, o que gera a sensação de “parte funciona, parte não”.
  • Topologia e múltiplos caminhos: em redes complexas, pode haver rotas concorrentes. O gateway pode preferir outro caminho para certos destinos, dependendo do routing e das métricas.
  • Criptografia vs. conectividade: o túnel pode estar ativo mesmo com falha de conectividade entre as redes internas. Por isso, é essencial checar rotas, regras e seletores de tráfego.

O que você pode concluir com segurança (e o que não concluir)

Se você quer reduzir incerteza, trate o diagnóstico como uma sequência: (1) conectividade entre gateways, (2) compatibilidade de parâmetros para negociação, (3) definição de quais redes entram no túnel, (4) rotas e políticas para encaminhar tráfego dentro da VPN.

Por outro lado, evite assumir que “túnel estabelecido” significa “acesso garantido”. Em VPN site-to-site, o acesso final depende de configurações de rede nos dois lados. O mesmo vale para qualquer suposição de desempenho ou cobertura total: sem validação, o resultado pode variar por tecnologia, topologia e políticas envolvidas.