Site-naar-site-VPN werkt maar één kant op: twee verschillende fouten

Locatie A bereikt B, B bereikt A niet, en de tunnel ziet er in beide richtingen goed uit. Bepaal voordat u de tunnel aanraakt welke fout u werkelijk hebt. Een nieuwe verbinding die op B wordt gestart en wordt geweigerd, en een antwoord op een verbinding die op A is gestart en nooit aankomt, veroorzaken vergelijkbare klachten en volledig verschillende diagnoses. Het ene is een beleids- of routeprobleem op het pad; het andere is een retourpad- of toestandsprobleem voor verkeer dat al was toegestaan.

Dat onderscheid bepaalt welke opdrachten de moeite waard zijn.

Twee fouten die er identiek uitzien

In het eerste geval stuurt de host van B een SYN naar A, en er komt niets terug. In het tweede opent de host van A met succes een sessie en het antwoord verdwijnt op de terugweg. Beide gebruikers zeggen dat de verbinding eenrichtingsverkeer is, en beiden beschrijven een pakket dat verdween, dus de beschrijving alleen kan ze niet scheiden.

Vraag welke kant de mislukte poging begon. Dat ene feit haalt de helft van de mogelijke oorzaken weg.

Controleer daarna of de test steeds dezelfde hosts en dezelfde dienst gebruikte. Een ping van de ene kant en een verbinding naar een gedeelde map van de andere kant testen twee verschillende dingen, en een diagnose vanaf de gateway kan een tunneladres kiezen dat geen enkel gebruikersverkeer ooit gebruikt.

Geval één: het retourpad ontbreekt

Een externe server die via een andere standaardgateway antwoordt, kan het verzoek ontvangen en het antwoord elders heen routeren. Stateful firewalls laten het asymmetrische antwoord dan vallen omdat het niet bij een bestaande stroom past, wat er precies uitziet als een richting die nooit werkte. Vertaling voegt nog een variant toe: de bestemming ziet een vertaalde bron en antwoordt daarop, dus een regel voor het oorspronkelijke adres past nooit.

Controleer het adres dat de bestemming na vertaling echt ziet, en de retourroute voor dat adres in plaats van voor het oorspronkelijke subnet.

Geval twee: het beleid stond het nooit toe

Het omgekeerde geval is eenvoudiger en gewoner dan het lijkt: één kantoor moet een centrale dienst gebruiken en nooit verbindingen naar het centrum starten. Die asymmetrie is een bewuste toegangsbeslissing, en de tunnel werkt zoals ontworpen. Lees het toegangsbeleid voordat u enige tunnelinstelling wijzigt. Het document, niet de pakketopname, zegt welke richting bedoeld was. Een opname kan alleen laten zien wat er gebeurde, niet wat was toegestaan.

Als tweerichtingsinitiatie echt nodig is, voeg dan de toestemming voor de specifieke dienst toe via de ondersteunde regelset van het platform. Elk subnet wederzijds vertrouwd maken om één toepassing te repareren verandert een smalle eis in een brede toestemming, en die ruil wordt achteraf zelden herzien.

Vergelijk voor en na op dezelfde hosts

Bekijk beide uiteinden van dezelfde poging, niet twee afzonderlijke pogingen. Neem op bij de gateway van de host die begint en bij de bestemming, en vergelijk dan wat binnenkwam, wat wegging en welk adres de andere kant zag.

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

Als de opname bij de bestemming het verzoek met een onverwacht bronadres toont, ligt het antwoord in vertaling of routering, niet in het beveiligingsbeleid van de tunnel. Als de bestemming helemaal geen verzoek toont, heeft het pakket het beschermde pad nooit gepasseerd.

Herhaal na een correctie dezelfde test vanaf dezelfde host en bevestig dat niet-gerelateerde toegang nog steeds wordt geweigerd. Een tunnelstatus van “established” ondersteunt op zichzelf geen van beide conclusies.