VPN site a site funciona em apenas um sentido: duas falhas diferentes

O site A alcança B, B não alcança A, e o túnel parece correto nos dois sentidos. Antes de mexer no túnel, decida qual falha você realmente tem. Uma conexão nova iniciada em B e recusada e uma resposta a uma conexão iniciada em A que nunca chega produzem queixas semelhantes e diagnósticos completamente diferentes. Uma é um problema de política ou de rota no caminho; a outra é um problema de caminho de retorno ou de estado para tráfego que já era permitido.

Essa distinção decide quais comandos vale a pena executar.

Duas falhas que parecem idênticas

No primeiro caso, o host de B envia um SYN para A, e nada volta. No segundo, o host de A abre uma sessão com sucesso e a resposta desaparece no caminho de volta. Os dois usuários dizem que o link é unidirecional, e ambos descrevem um pacote que sumiu, então a descrição sozinha não consegue separá-los.

Pergunte qual lado iniciou a tentativa que falhou. Esse único fato elimina metade das causas possíveis.

Depois verifique se o teste usou os mesmos hosts e o mesmo serviço o tempo todo. Um ping de um lado e uma conexão a uma pasta compartilhada do outro testam duas coisas diferentes, e um diagnóstico feito a partir do gateway pode escolher um endereço de túnel que nenhum tráfego de usuário usa.

Caso um: falta o caminho de retorno

Um servidor remoto que responde por outro gateway padrão pode receber a requisição e rotear a resposta para outro lugar. Firewalls com controle de estado descartam então a resposta assimétrica porque ela não corresponde a um fluxo estabelecido, o que parece exatamente um sentido que nunca funcionou. A tradução adiciona outra versão: o destino vê uma origem traduzida e responde a ela, então uma regra escrita para o endereço original nunca corresponde.

Verifique o endereço que o destino realmente observa depois da tradução, e a rota de retorno para esse endereço em vez de para a sub-rede original.

Caso dois: a política nunca permitiu

O caso oposto é mais simples e mais comum do que parece: um escritório deve consumir um serviço central e nunca iniciar conexões para o centro. Essa assimetria é uma decisão de acesso deliberada, e o túnel funciona como projetado. Leia a política de acesso antes de mudar qualquer ajuste do túnel. O documento, não a captura de pacotes, informa qual sentido era pretendido. Uma captura só pode mostrar o que aconteceu, não o que estava autorizado.

Se a iniciação bidirecional for realmente necessária, acrescente a permissão do serviço específico pelo conjunto de regras suportado pela plataforma. Tornar todas as sub-redes mutuamente confiáveis para corrigir uma aplicação transforma um requisito estreito em permissão ampla, e essa troca raramente é revista depois.

Compare antes e depois nos mesmos hosts

Observe as duas pontas da mesma tentativa, não duas tentativas separadas. Capture no gateway do host que inicia e no destino, e depois compare o que entrou, o que saiu e qual endereço o lado remoto viu.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Se a captura no destino mostrar a requisição com um endereço de origem inesperado, a resposta está na tradução ou no roteamento, não na política de segurança do túnel. Se o destino não mostrar nenhuma requisição, o pacote nunca atravessou o caminho protegido.

Depois de uma correção, repita o mesmo teste a partir do mesmo host e confirme que o acesso não relacionado continua negado. Um estado de túnel “established” não sustenta nenhuma das duas conclusões sozinho.