Definição e objetivo

Uma VPN site a site é uma conexão segura entre duas redes (por exemplo, matriz e filial), normalmente estabelecida entre roteadores ou firewalls. O objetivo é permitir que dispositivos de cada local alcancem recursos do outro pela internet, usando um túnel criptografado e políticas que limitam o que pode trafegar.

Modelo simples: o que precisa estar “combinado”

Pense na configuração como três blocos que precisam ficar consistentes:

  1. Identificação e autenticação: os dois lados precisam conseguir se reconhecer (por certificados ou chaves pré-compartilhadas, dependendo do método suportado).
  2. Criptografia e parâmetros do túnel: ambos os lados devem usar o mesmo conjunto de algoritmos e modos de troca de chaves, além de chaves válidas.
  3. O que será roteado pelo túnel: você define quais redes/sub-redes de cada site serão acessadas remotamente e quais regras devem valer.

Na prática, ao configurar, você informa os endereços dos equipamentos na internet (ou identificadores equivalentes) e as redes internas que devem atravessar a VPN.

Componentes que entram na configuração

Para que funcione, costuma ser necessário preparar:

  • Endereços e sub-redes internas: defina os ranges (ex.: 10.0.10.0/24 no site A e 10.0.20.0/24 no site B). Se houver sobreposição de sub-redes, o roteamento pelo túnel fica ambíguo.
  • Alcance do tráfego: escolha quais sub-redes remotas o túnel deve transportar. Nem todo tráfego precisa (ou deve) atravessar.
  • Políticas de segurança no equipamento: além do túnel, regras de firewall/ACL locais podem bloquear ou permitir o tráfego “dentro” e “fora” da VPN.
  • Roteamento: o equipamento do site A precisa saber como chegar às sub-redes do site B e vice-versa. Isso pode ser feito por rotas estáticas ou dinâmicas, conforme o suporte do seu equipamento.

Se você usa NAT no caminho (por exemplo, IP público no roteador e endereços privados internos), você precisa garantir que as políticas de NAT e a detecção do tráfego sejam compatíveis com a forma como o túnel é estabelecido.

Exceções, limites e o que mais causa falhas

Alguns problemas comuns mudam o resultado mesmo quando a configuração “parece correta”:

  • Sub-redes sobrepostas: impede distinguir “qual rede” deve ser acessada no lado remoto.
  • Firewalls ou regras de borda: podem bloquear o tráfego de negociação e/ou o tráfego encapsulado do túnel.
  • Incompatibilidade de parâmetros: algoritmos e métodos de troca precisam ser compatíveis entre os dois lados.
  • NAT e endereçamento: cenários com NAT, ou com mudanças frequentes de IP público, podem exigir ajustes para manter o túnel estável.

Como não há um padrão único para todos os equipamentos, vale tratar a configuração como um “casamento” entre as opções do site A e as do site B, principalmente em autenticação, criptografia e escopo das redes.

Como validar antes de considerar “pronto”

Você pode verificar a configuração por etapas, com foco em evidências:

  1. Verificar se o túnel sobe: confirme logs/status no equipamento e se a negociação ocorre com sucesso.
  2. Validar rotas e escopo: confirme que as sub-redes que você definiu aparecem como destinos do túnel em ambos os lados.
  3. Testar conectividade entre sub-redes: pings/consultas e conexões controladas a partir de hosts das redes internas (sempre que permitido).
  4. Checar regras de firewall/ACL: se o túnel estiver ativo mas o tráfego não passar, normalmente a causa está em políticas locais.

Se você encontrar inconsistências, ajuste primeiro endereços/sub-redes, depois parâmetros criptográficos/autenticação, e por último regras de firewall/roteamento. Assim, você reduz o número de variáveis simultâneas.