Site-to-site-VPN fungerar bara åt ett håll: två olika fel

Plats A når B, B når inte A, och tunneln ser bra ut i båda riktningarna. Innan du rör tunneln måste du avgöra vilket fel du egentligen har. En ny anslutning som startas på B och avvisas, och ett svar på en anslutning som startats på A som aldrig kommer fram, ger liknande klagomål och helt olika diagnoser. Det ena är ett policy- eller routingproblem på vägen; det andra är ett returvägs- eller tillståndsproblem för trafik som redan var tillåten.

Den skillnaden avgör vilka kommandon som är värda att köra.

Två fel som ser identiska ut

I det första fallet skickar B:s värd ett SYN till A, och ingenting kommer tillbaka. I det andra öppnar A:s värd en session med framgång och svaret försvinner på vägen tillbaka. Båda användarna säger att länken är enkelriktad, och båda beskriver ett paket som försvann, så beskrivningen ensam kan inte skilja dem åt.

Fråga vilken sida som startade det misslyckade försöket. Det enda faktumet tar bort hälften av de möjliga orsakerna.

Kontrollera sedan att testet använde samma värdar och samma tjänst hela tiden. En ping från ena sidan och en filsdelningsanslutning från den andra testar två olika saker, och en diagnostik från gatewayen kan välja en tunneladress som ingen användartrafik någonsin använder.

Fall ett: returvägen saknas

En fjärrserver som svarar via en annan standardgateway kan ta emot begäran och routa svaret någon annanstans. Tillståndsspårande brandväggar kastar då det asymmetriska svaret eftersom det inte matchar ett upprättat flöde, vilket ser exakt ut som en riktning som aldrig fungerade. Översättning lägger till en annan variant: destinationen ser en översatt källa och svarar på den, så en regel skriven för den ursprungliga adressen matchar aldrig.

Kontrollera adressen som destinationen faktiskt ser efter översättningen, och returvägen för den adressen i stället för för det ursprungliga subnätet.

Fall två: policyn tillät det aldrig

Det motsatta fallet är enklare och vanligare än det ser ut: ett kontor ska använda en central tjänst och aldrig starta anslutningar in mot centret. Den asymmetrin är ett medvetet åtkomstbeslut, och tunneln fungerar som designat. Läs åtkomstpolicyn innan du ändrar någon tunnelinställning. Dokumentet, inte paketfångsten, anger vilken riktning som var avsedd. En fångst kan bara visa vad som hände, inte vad som var tillåtet.

Om tvåvägsinitiering verkligen behövs, lägg till behörigheten för den specifika tjänsten via plattformens regeluppsättning som stöds. Att göra varje subnät ömsesidigt betrott för att laga en applikation gör ett snävt krav till en bred behörighet, och den affären granskas sällan i efterhand.

Jämför före och efter på samma värdar

Följ båda ändarna av samma försök, inte två separata försök. Fånga på gatewayen för värden som startar och på destinationen, jämför sedan vad som kom in, vad som gick ut och vilken adress den avlägsna sidan såg.

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

Om fångsten på destinationen visar begäran med en oväntad källadress ligger svaret i översättningen eller routingen, inte i tunnelns säkerhetspolicy. Om destinationen inte visar någon begäran alls korsade paketet aldrig den skyddade vägen.

Efter en korrigering, upprepa samma test från samma värd och bekräfta att orelaterad åtkomst fortfarande nekas. En tunnelstatus på “established” stöder ingen av de två slutsatserna på egen hand.