Definição e ideia central

VPN site a site é um tipo de VPN que conecta duas redes inteiras por meio de um túnel criptografado estabelecido entre dispositivos de borda (como firewalls ou roteadores). A proposta é que os equipamentos de cada lado tratem o tráfego remoto como parte da “mesma conectividade lógica”, respeitando as políticas e rotas definidas.

Na prática, você não está criando uma VPN “para um único usuário”, e sim para permitir comunicação entre redes: por exemplo, entre uma rede corporativa e a rede de uma filial, ou entre duas redes de datacenters.

Modelo simples de funcionamento (do tráfego ao túnel)

O fluxo típico pode ser entendido em camadas:

  1. Negociação do túnel: os dispositivos dos dois lados concordam em parâmetros de autenticação e criptografia. Sem essa etapa compatível, o túnel não se estabelece.

  2. Criptografia e encapsulamento: quando uma rede envia tráfego destinado a outra rede pela “direção remota”, esse tráfego é encapsulado e protegido conforme as opções negociadas.

  3. Decisão de roteamento: os pacotes precisam ser encaminhados para o túnel. Por isso, não basta “ter VPN”: é necessário que as rotas (e, muitas vezes, as políticas) digam que o destino remoto deve sair pela interface do túnel.

  4. Regras de filtragem: mesmo com túnel, firewalls podem bloquear. É comum existir uma combinação de regras do lado local e do lado remoto (ACLs, políticas de firewall, permissões por sub-rede e protocolo).

  5. Entrega ao destino: uma vez de volta ao lado receptor, o tráfego segue para a rede correspondente, novamente obedecendo às políticas internas do lado receptor.

O que você precisa decidir ao configurar

Uma configuração de VPN site a site costuma girar em torno de informações que precisam estar alinhadas nos dois lados:

  • Quais redes serão alcançadas: normalmente você define sub-redes “locais” e “remotas” (por exemplo, 10.0.1.0/24 do lado A e 10.0.2.0/24 do lado B).
  • Como o tráfego chega ao túnel: rotas estáticas ou dinâmica (dependendo do equipamento e do desenho) precisam apontar o destino remoto para o túnel.
  • Autenticação e chaves: pode haver chave pré-compartilhada ou certificados, conforme a solução. Incompatibilidade aqui impede o estabelecimento ou derruba o túnel.
  • Parâmetros criptográficos: algoritmos, modos e versões precisam coincidir.
  • Políticas de acesso: regras que definem o que pode trafegar entre as redes (TCP, UDP, ICMP, portas específicas), além de margens como NAT ou sem NAT, quando aplicável.

Como referência mental: se o túnel não sobe, o problema tende a ser compatibilidade/credenciais/parâmetros. Se o túnel sobe, mas não há tráfego, o problema tende a ser roteamento e políticas (o “mapeamento” do tráfego para o túnel e as regras de permissão).

Limitações e exceções que mudam o resultado

Existem algumas limitações comuns que alteram a expectativa inicial:

  1. VPN não resolve “roteamento por magia”: se não existir rota para o destino remoto apontando para o túnel, o tráfego pode simplesmente não entrar nele. Do mesmo modo, se existir rota, mas estiver conflitando com outras rotas, pode ocorrer comportamento inesperado.

  2. Tráfego assimétrico pode quebrar fluxos: para algumas aplicações, especialmente as mais sensíveis a estado, é importante que o retorno siga o caminho previsto. Em redes complexas, isso pode exigir ajustes adicionais.

  3. Firewall ainda vale: a existência do túnel não significa que tudo está liberado. Regras insuficientes são uma causa frequente de “VPN está ativa, mas não funciona”.

  4. NAT e sobreposição de sub-redes complicam: se as duas redes usam faixas IP idênticas (sobreposição), o tráfego fica ambíguo. Já NAT pode exigir configurações específicas para que o destino e a tradução funcionem do jeito esperado.

  5. Desempenho não é ilimitado: a taxa efetiva depende de CPU, aceleração criptográfica, tamanho de pacotes, latência e largura de banda. Em cenários de alto tráfego, pode ser necessário ajustar parâmetros ou confirmar capacidade.

  6. Variedade de implementações: diferentes produtos e cenários podem adotar mecanismos e termos próprios. Por isso, “como configurar” varia bastante e você deve seguir o manual do seu equipamento para os campos exatos.

Como você pode verificar na prática (sem adivinhar)

Você pode validar o cenário por etapas, para separar “túnel” de “tráfego”:

  1. Verifique se o túnel está estabelecido: no dispositivo de borda, procure indicadores de status (por exemplo, fases “ativas”, tempo de vida do túnel, contadores de pacotes criptografados). Se não estiver estabelecido, foque em credenciais e compatibilidade.

  2. Confirme rotas para as sub-redes remotas: teste se existe regra de encaminhamento para o destino remoto através do túnel. Uma rota ausente (ou apontando para outro lugar) costuma explicar a ausência de conectividade.

  3. Checagem de políticas e regras: verifique se as regras permitem o tráfego esperado entre as sub-redes. Considere protocolo e portas.

  4. Teste direcionado por sub-rede: em vez de testar “tudo”, teste primeiro um par de IPs (um host do lado A para um host do lado B) e depois amplie. Isso reduz a chance de você mascarar o problema.

  5. Observe contadores e logs: números de pacotes que entram e saem do túnel, além de logs de rejeição no firewall, ajudam a entender se o bloqueio acontece antes ou depois do encapsulamento.

  6. Valide com testes simples de conectividade: ping (quando permitido), teste TCP/UDP para portas específicas e, em cenários controlados, trace/diagnóstico equivalente para identificar onde o fluxo para.

Se você concluir que o túnel sobe e mesmo assim não há tráfego, a causa mais comum costuma estar em rotas/políticas incompatíveis, sobreposição de redes, NAT não previsto ou regras de firewall bloqueando o tráfego.

Diferenças importantes para não confundir

É útil distinguir VPN site a site de outras abordagens:

  • VPN site a site x VPN remota para usuários: no site a site, o foco é a conectividade entre redes; no remoto, o foco é acesso de um dispositivo/usuário.
  • VPN x tunelamento “sem criptografia”: nem todo “túnel” equivale a VPN; VPN normalmente implica criptografia e autenticação, e isso muda a forma de validar o funcionamento.
  • Conexão direta x VPN com criptografia: mesmo quando a topologia parece parecida, a VPN adiciona etapas de negociação e proteção que podem impactar resolução de problemas e desempenho.

Quando você entende essas diferenças, fica mais fácil interpretar o que significa “funcionar”: o túnel está ativo, e os fluxos entre sub-redes estão realmente permitidos e roteados.

Cenários típicos de uso e o que testar primeiro

Em uso corporativo, a VPN site a site costuma ser buscada para conectar:

  • Filiais e matriz: validar sub-redes, portas necessárias e políticas entre escritórios.
  • Integração entre redes de operação: ajustar rotas para que sistemas dependentes de rede encontrem o destino correto.
  • Conectividade entre ambientes: garantir consistência entre endereços e permissões.