strongSwan på EC2: låt VPC:n routa arbetslasten

Tunneln är uppe, gateway-instansen kan pinga fjärrnätet, och applikationsinstansen bredvid når ingenting. Inget är trasigt. Testet som lyckades utgick från VPN-värden, och det frågade aldrig om den värden kunde bära en annan källadress genom samma IPsec-relation. Den här runbooken stänger gapet i fyra steg, i den ordning som håller varje fel synligt.

Skriv ned de fyra adresserna först

Varje steg nedan hänvisar till dem, så fyll i dem för ditt eget konto innan du rör en routningstabell.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

Exemplet förutsätter en godkänd, fungerande policybaserad IPsec-anslutning och ett flöde som bevarar källan. Detta är inte en NAT:ad fjärråtkomstklient som lånar en tilldelad adress, och den skillnaden avgör om selektorerna måste ändras.

Steg 1: ge arbetslastens subnät en route

Routningstabellen som faktiskt är kopplad till arbetslastens subnät behöver en väg för fjärrprefixet som pekar mot gatewayens nätverksgränssnitt. En gästroute installerad inne i instansen är inte en post i den AWS-routningstabellen, och ingen mängd strongSwan-konfiguration skapar en.

AWS vägledning för routning via enhet beskriver mål av typen nätverksgränssnitt och kravet på käll-/destinationskontroll för instansen som vidarebefordrar. Begränsa den kontrolländringen till gateway-rollen och lämna vanliga applikationsinstanser i fred.

Ersätt inte VPC:ns lokala route eller varje befintlig post för att göra plats för ett godkänt nät. Inspektera vad som är kopplat och aktivt, i stället för vad en konsolsida visar för en routningstabell ingen använder. Två tabeller som ser likadana ut kan ha olika kopplingar. Den som spelar roll är den som arbetslastens subnät är kopplat till.

Steg 2: slå på vidarebefordran på gästen

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Kärnan måste vidarebefordra och värdens brandvägg måste tillåta genomfarten. Lägg till de avsedda vidarebefordringsreglerna för arbetslastens och fjärrprefixen i stället för att acceptera allt, och bekräfta att gateway-subnätet behåller en användbar transportroute för sin egen trafik.

Säkerhetsgrupper är där detta steg oftast fastnar. En mellanliggande enhet ärver inte säkerhetsgruppernas referensbeteende från direkt instanskommunikation, så en regel som kopierats från ett exempel med hanterad Client VPN kanske aldrig matchar. Kontrollera säkerhetsgruppen och subnätets ACL på den faktiska vägen, åt båda hållen.

Steg 3: bredda selektorerna till de verkliga källorna

En policy som bara täcker 10.60.1.10/32 på AWS-sidan förklarar en framgång som utgick från gatewayen utan att täcka 10.60.2.20. En route mot fjärrdestinationen breddar inte en trafikselektor, och det är den andra halvan av samma överraskning.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Om den överenskomna designen skyddar hela VPC:n måste båda parter acceptera 10.60.0.0/16 och 10.90.0.0/24. Om den skyddar en enda arbetslast, använd medvetet det smalare prefixet. Kontrollera hur som helst den installerade CHILD-SA-policyn, för en konfiguration du har redigerat och en part som har snävat in den annorlunda är inte samma överenskommelse.

Fjärrplatsen måste också routa svar för de bevarade VPC-källorna tillbaka genom den avsedda IPsec-gatewayen. Behåll det stödda NAT-undantaget för skyddad trafik där andra käll-NAT-regler finns; att översätta en icke godkänd arbetslast till en tillåten värdadress är ett annat identitetskontrakt, inte en genväg till den åtkomst du ville ha.

Steg 4: verifiera och rulla sedan tillbaka vid behov

Testa från själva arbetslasten med en ny tillåten applikationsoperation och upprepa sedan med en destination som borde uteslutas. Anteckna källadressen som fjärrtjänsten ser och returvägen den använder. En gateway-ping eller grön IKE-status är inte det testet.

Om arbetslasten fortfarande misslyckas medan gatewayen fungerar, gå tillbaka genom stegen i ordning: selektor, sedan vidarebefordran och säkerhetsgrupper, sedan den kopplade routningstabellen. Var och en har ett tydligt symtom, och gissningar hoppar över den som faktiskt är fel.

Tillbakarullningen vänder samma ordning. Ta bort arbetslastens subnätsroute sist, efter att ha återställt de tidigare selektorerna, så att du inte lämnar ett subnät som pekar på en gateway som inte längre skyddar dess källor. Egen hosting kan tjäna mer än gateway-värden när dessa kontrakt håller, och AWS-hanterad Site-to-Site VPN är en annan driftsmodell där strongSwan i stället kan sitta på kundgateway-sidan.