O que é uma VPN site a site

VPN site a site é uma forma de conectar redes inteiras por meio de um túnel criptografado entre dois equipamentos (ou dois ambientes) na borda de cada local. Em vez de criar uma conexão para um usuário individual, a ideia é que o tráfego entre sub-redes localizadas em sites diferentes atravesse esse túnel.

Na prática, isso costuma envolver:

  • Autenticação entre as pontas do túnel (para saber que “é” de fato o outro lado).
  • Criptografia do tráfego no caminho.
  • Definição de quais endereços/sub-redes devem trafegar pelo túnel (políticas de tráfego/roteamento).
  • Regras no dispositivo para permitir e encaminhar o tráfego correto.

Um modelo simples de funcionamento

Pense no túnel como um “corredor” entre dois roteadores/firewalls. Quando um host do Site A tenta acessar um destino que está no Site B, o dispositivo do Site A:

  1. identifica que o destino pertence à rede remota esperada,
  2. decide que esse tráfego deve ir pelo túnel,
  3. encapsula o pacote de acordo com o método de VPN,
  4. envia ao outro lado.

No Site B, a ponta receptora:

  1. valida a sessão do túnel (autenticação e integridade),
  2. decapsula o pacote,
  3. encaminha para a rede local correspondente.

Esse encadeamento depende do que está configurado em ambos os lados: parâmetros do túnel, chaves/segredos (ou certificados, conforme o método), e o “mapa” do que deve ser roteado via VPN.

Componentes e decisões que mais afetam a configuração

Uma configuração de VPN site a site raramente falha por um “detalhe isolado”; mais comum é faltar alinhamento entre as partes. Em geral, os pontos que exigem mais atenção são:

1) Identidade e autenticação das pontas

As duas extremidades precisam reconhecer uma à outra. Isso pode ser feito por chaves compartilhadas ou por certificados, dependendo do tipo de solução e do método. Se a autenticação não casar, o túnel tende a não estabelecer ou a não manter sessões.

2) Método criptográfico e parâmetros de sessão

Mesmo quando a “ideia” de VPN está correta, detalhes como algoritmos aceitos, duração de chaves/renovação e configuração de segurança podem impedir a negociação.

3) Endereçamento e sobreposição de redes

Se as redes internas dos dois sites usam os mesmos intervalos de IP (ex.: ambos têm 192.168.1.0/24), o roteamento via túnel pode ficar ambíguo. Nesses casos, a VPN pode até subir, mas o tráfego pode não chegar ao destino certo, ou pode ser descartado por políticas.

4) Rotas e políticas de tráfego

Definir “quais redes atravessam o túnel” é essencial. Além do roteamento, podem existir políticas (por exemplo, permitir apenas certos protocolos/portas) que limitam o que passa. Uma falha típica é ter o túnel ativo, mas o encaminhamento não liberar a comunicação.

5) NAT e endereços na borda

Quando há NAT (por exemplo, múltiplos dispositivos atrás de um IP público compartilhado), a forma como o tráfego é traduzido pode afetar a identificação do caminho e o funcionamento do túnel, especialmente se as redes internas ou as portas de origem/destino não forem consistentes entre as pontas.

Diferenças importantes: site a site vs. VPN de acesso remoto

É comum confundir VPN site a site com outros cenários. Em uma VPN de acesso remoto, o foco é um cliente (por exemplo, um notebook) criando sessão com o serviço remoto. Já na site a site, a conectividade é entre redes.

Isso muda o que você deve validar:

  • Em site a site, o “contrato” principal é roteamento e encaminhamento entre sub-redes.
  • Em acesso remoto, normalmente o contrato é a atribuição de rotas para o dispositivo do usuário e a forma como a autenticação do cliente ocorre.

Outra diferença prática é a superfície de falhas: em site a site, problemas de sobreposição de endereços e regras de firewall/roteador tendem a aparecer mais cedo, porque o tráfego entre redes inteiras é o objetivo.

Limitações e exceções que podem mudar o resultado

Alguns fatores mudam significativamente a expectativa de “funcionar” e devem ser considerados desde o início:

  1. Túnel ativo não significa conectividade completa. A sessão pode estar negociada, mas regras de firewall, rotas ausentes ou políticas restritivas podem bloquear o tráfego.

  2. Sobreposição de sub-redes pode causar ambiguidade. Mesmo com autenticação e criptografia corretas, destinos podem não ser atingidos como esperado.

  3. Mudanças de IP público e reendereçamento. Se a ponta em um site muda de IP público ou a rota de borda muda sem atualização coerente (ou sem suporte para esse cenário), o túnel pode perder conectividade.

  4. Desempenho pode variar. Criptografia e encapsulamento adicionam custo. Além disso, latência, perda e gargalos do link afetam o comportamento geral.

  5. Nem todo tráfego é igualmente fácil. Alguns tipos de tráfego podem exigir configurações adicionais (por exemplo, no nível de protocolos e portas) para atravessar políticas.

Como não há informações de fabricante, modelo ou método específico, vale tratar essas limitações como gerais e validar conforme as capacidades e a documentação do equipamento utilizado em cada ponta.

Verificações práticas para testar e otimizar (sem suposições)

A melhor forma de “otimizar” uma VPN site a site é primeiro verificar o que está funcionando e depois reduzir hipóteses. Um roteiro de checagem útil:

1) Confirmar que o túnel está estabelecido nos dois lados

Verifique sinais de que a sessão do túnel está em estado ativo/negociado em ambas as pontas. Se houver logs, procure por falhas de autenticação, incompatibilidade de parâmetros de segurança ou erros de negociação.

2) Validar as redes anunciadas/permitidas

Confira se as sub-redes que deveriam atravessar a VPN estão declaradas do lado correto e se ambas as pontas “concordam” com o que é destino remoto.

3) Conferir regras de firewall/ACL

Mesmo com rotas, regras de filtragem podem bloquear o tráfego. Verifique se existe permissão para os protocolos esperados (por exemplo, ICMP para testes básicos e, depois, o tráfego real necessário).

4) Testar fluxo com endpoints conhecidos

Escolha um host no Site A e tente alcançar um host específico no Site B. Se o teste falhar, reduza variáveis: teste primeiro conectividade básica, depois serviços específicos, e por fim revise roteamento e políticas.

5) Verificar se o roteamento interno está consistente

Garanta que, no Site A, o caminho até o destino remoto realmente aponta para o túnel (e no Site B, o retorno também). Tráfego de ida pode passar, mas retorno pode falhar por rota ausente ou regra assimétrica.

6) Revisar impacto de NAT e endereços de borda

Se o ambiente usa NAT, valide se a tradução na borda não contradiz a forma como o túnel espera ver origem/destino.