El VPN de lloc a lloc només funciona en un sentit: dues avaries diferents

El lloc A arriba a B, B no pot arribar a A, i el túnel sembla correcte en tots dos sentits. Abans de tocar el túnel, decidiu quina avaria teniu realment. Una connexió nova iniciada a B que es rebutja i una resposta a una connexió iniciada a A que no arriba mai produeixen queixes semblants i diagnòstics completament diferents. Una és un problema de política o d’encaminament al camí; l’altra és un problema de camí de tornada o d’estat per a un trànsit que ja estava permès.

Aquesta distinció decideix quines ordres val la pena executar.

Dues avaries que semblen idèntiques

En el primer cas, l’amfitrió de B envia un SYN a A i no torna res. En el segon, l’amfitrió d’A obre una sessió amb èxit i la resposta desapareix de tornada. Tots dos usuaris diuen que l’enllaç va en un sol sentit, i tots dos descriuen un paquet que ha desaparegut, així que la descripció sola no els pot separar.

Pregunteu quin costat va iniciar l’intent que ha fallat. Aquest sol fet elimina la meitat de les causes possibles.

Després comproveu que la prova ha fet servir els mateixos amfitrions i el mateix servei durant tot el procés. Un ping des d’un costat i una connexió a una carpeta compartida des de l’altre proven dues coses diferents, i un diagnòstic fet des de la passarel·la pot triar una adreça de túnel que cap trànsit d’usuari no utilitza.

Cas u: falta el camí de tornada

Un servidor remot que respon per una passarel·la predeterminada diferent pot rebre la petició i encaminar la resposta a un altre lloc. Els tallafocs amb seguiment d’estat descarten llavors la resposta asimètrica perquè no coincideix amb un flux establert, cosa que sembla exactament un sentit que no ha funcionat mai. La traducció afegeix una altra versió: la destinació veu un origen traduït i hi respon, així que una regla escrita per a l’adreça original no coincideix mai.

Comproveu l’adreça que la destinació observa realment després de la traducció, i la ruta de tornada per a aquesta adreça en lloc de per a la subxarxa original.

Cas dos: la política no ho va permetre mai

El cas oposat és més simple i més habitual del que sembla: una oficina ha de consumir un servei central i no ha d’iniciar mai connexions cap al centre. Aquesta asimetria és una decisió d’accés deliberada, i el túnel funciona tal com es va dissenyar. Llegiu la política d’accés abans de canviar cap paràmetre del túnel. El document, no la captura de paquets, indica quin sentit es pretenia. Una captura només pot mostrar què va passar, no què estava autoritzat.

Si realment cal iniciar en tots dos sentits, afegiu el permís del servei concret mitjançant el conjunt de regles compatible de la plataforma. Fer que totes les subxarxes confiïn mútuament per arreglar una aplicació converteix un requisit estret en un permís ampli, i aquest intercanvi poques vegades es revisa després.

Compareu abans i després als mateixos amfitrions

Observeu tots dos extrems del mateix intent, no dos intents separats. Captureu a la passarel·la de l’amfitrió que inicia i a la destinació, i després compareu què va entrar, què va sortir i quina adreça va veure el costat remot.

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

Si la captura a la destinació mostra la petició amb una adreça d’origen inesperada, la resposta és a la traducció o a l’encaminament, no a la política de seguretat del túnel. Si la destinació no mostra cap petició, el paquet no va creuar mai el camí protegit.

Després d’una correcció, repetiu la prova idèntica des del mateix amfitrió i confirmeu que l’accés no relacionat continua denegat. Un estat de túnel “established” no sosté cap de les dues conclusions per si sol.