O VPN de sitio a sitio só funciona nun sentido: dous fallos distintos

O sitio A chega a B, B non chega a A, e o túnel parece correcto nos dous sentidos. Antes de tocar o túnel, decida que fallo ten realmente. Unha conexión nova iniciada en B que se rexeita e unha resposta a unha conexión iniciada en A que nunca chega producen queixas parecidas e diagnósticos completamente distintos. Un é un problema de política ou de ruta no camiño; o outro é un problema de ruta de retorno ou de estado para un tráfico que xa estaba permitido.

Esa distinción decide que comandos paga a pena executar.

Dous fallos que parecen idénticos

No primeiro caso o host de B envía un SYN a A e non volve nada. No segundo o host de A abre unha sesión con éxito e a resposta desaparece á volta. Ambos os usuarios din que a ligazón é unidireccional, e ambos describen un paquete que desapareceu, así que a descrición por si soa non pode separalos.

Pregunte que lado iniciou o intento que fallou. Ese único dato elimina a metade das causas posibles.

Despois comprobe que a proba usou os mesmos hosts e o mesmo servizo de principio a fin. Un ping desde un lado e unha conexión a un cartafol compartido desde o outro proban dúas cousas distintas, e un diagnóstico feito desde a pasarela pode escoller un enderezo de túnel que ningún tráfico de usuario usa.

Caso un: falta a ruta de retorno

Un servidor remoto que responde por outra pasarela predeterminada pode recibir a petición e encaminar a resposta a outro sitio. Os devasas con seguimento de estado descartan entón a resposta asimétrica porque non coincide cun fluxo establecido, o que parece exactamente un sentido que nunca funcionou. A tradución engade outra versión: o destino ve unha orixe traducida e responde a ela, así que unha regra escrita para o enderezo orixinal nunca coincide.

Comprobe o enderezo que o destino observa realmente despois da tradución, e a ruta de retorno para ese enderezo en lugar de para a subrede orixinal.

Caso dous: a política nunca o permitiu

O caso oposto é máis simple e máis frecuente do que parece: unha oficina debe consumir un servizo central e nunca iniciar conexións cara ao centro. Esa asimetría é unha decisión de acceso deliberada, e o túnel funciona tal como se deseñou. Lea a política de acceso antes de cambiar calquera axuste do túnel. O documento, non a captura de paquetes, indica que sentido se pretendía. Unha captura só pode mostrar que ocorreu, non que estaba autorizado.

Se de verdade fai falta iniciar nos dous sentidos, engada o permiso do servizo concreto mediante o conxunto de regras compatible da plataforma. Facer que todas as subredes confíen entre si para arranxar unha aplicación converte un requisito estreito nun permiso amplo, e ese intercambio raramente se revisa despois.

Compare antes e despois nos mesmos hosts

Observe ambos os extremos do mesmo intento, non dous intentos separados. Capture na pasarela do host que inicia e no destino, e despois compare que entrou, que saíu e que enderezo viu o lado remoto.

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 mostra a petición cun enderezo de orixe inesperado, a resposta está na tradución ou no enrutamento, non na política de seguridade do túnel. Se o destino non mostra ningunha petición, o paquete nunca cruzou a ruta protexida.

Tras unha corrección, repita a proba idéntica desde o host idéntico e confirme que o acceso non relacionado segue denegado. Un estado de túnel “established” non sostén ningunha das dúas conclusións por si só.