strongSwan på EC2: lad VPC'en rute arbejdsbyrden

Tunnelen er oppe, gateway-instansen kan pinge det eksterne netværk, og applikationsinstansen ved siden af kan ikke nå noget. Intet er i stykker. Testen, der lykkedes, startede på VPN-værten, og den spurgte aldrig, om den vært kunne bære en anden kildeadresse gennem det samme IPsec-forhold. Denne runbook lukker det hul i fire trin, i den rækkefølge, der holder hver fejl synlig.

Skriv de fire adresser ned først

Hvert trin nedenfor henviser til dem, så udfyld dem for din egen konto, før du rører en rutetabel.

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

Eksemplet forudsætter en godkendt, fungerende policybaseret IPsec-forbindelse og et kildetro flow. Det er ikke en NAT'et fjernadgangsklient, der låner én tildelt adresse, og den forskel afgør, om selectorerne skal ændres.

Trin 1: giv arbejdsbyrde-undernettet en rute

Den rutetabel, der faktisk er knyttet til arbejdsbyrde-undernettet, skal have en sti til det eksterne præfiks, der peger på gatewayens netværksinterface. En gæsterute installeret inde i instansen er ikke en post i den AWS-rutetabel, og ingen mængde strongSwan-konfiguration vil oprette en.

AWS' vejledning i routing via apparat beskriver netværksinterface-mål og kravet om kilde-/destinationskontrol for den videresendende instans. Begræns den kontrolændring til gateway-rollen, og lad almindelige applikationsinstanser være i fred.

Erstat ikke VPC'ens lokale rute eller hver eksisterende post for at gøre plads til ét godkendt netværk. Undersøg, hvad der er knyttet og aktivt, i stedet for hvad en konsolside viser for en rutetabel, ingen bruger. To tabeller, der ligner hinanden, kan have forskellige tilknytninger. Den, der betyder noget, er den, som arbejdsbyrde-undernettet er knyttet til.

Trin 2: slå videresendelse til på gæsten

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

Kernen skal videresende, og værtens firewall skal tillade gennemløbet. Tilføj de tilsigtede videresendelsesregler for arbejdsbyrde- og eksterne præfikser i stedet for at acceptere alt, og bekræft, at gateway-undernettet beholder en brugbar transportrute for sin egen trafik.

Sikkerhedsgrupper er der, hvor dette trin normalt går i stå. En mellemboks arver ikke sikkerhedsgruppereference-adfærden fra direkte instanskommunikation, så en regel kopieret fra et administreret Client VPN-eksempel matcher måske aldrig. Kontrollér sikkerhedsgruppen og undernet-ACL'en på den faktiske sti, i begge retninger.

Trin 3: udvid selectorerne til de rigtige kilder

En politik, der kun dækker 10.60.1.10/32 på AWS-siden, forklarer en succes med udgangspunkt i gatewayen uden at dække 10.60.2.20. En rute mod den eksterne destination udvider ikke en trafikselector, og det er den anden halvdel af den samme overraskelse.

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

Hvis det aftalte design beskytter hele VPC'en, skal begge parter acceptere 10.60.0.0/16 og 10.90.0.0/24. Hvis det beskytter én arbejdsbyrde, brug da bevidst det smallere præfiks. Under alle omstændigheder skal du undersøge den installerede CHILD-SA-politik, for en konfiguration, du har redigeret, og en part, der har indsnævret den anderledes, er ikke den samme aftale.

Det eksterne sted skal også route svar for de bevarede VPC-kilder tilbage gennem den tilsigtede IPsec-gateway. Behold den understøttede NAT-fritagelse for beskyttet trafik, hvor der findes andre kilde-NAT-regler; at oversætte en ikke-godkendt arbejdsbyrde til en tilladt værtadresse er en anden identitetskontrakt, ikke en genvej til den adgang, du ønskede.

Trin 4: verificér, og rul derefter tilbage om nødvendigt

Test fra selve arbejdsbyrden med en frisk tilladt applikationshandling, og gentag derefter med en destination, der bør udelukkes. Notér den kildeadresse, den eksterne tjeneste ser, og den returvej, den bruger. Et gateway-ping eller en grøn IKE-status er ikke den test.

Hvis arbejdsbyrden stadig fejler, mens gatewayen virker, gå tilbage gennem trinnene i rækkefølge: selector, derefter videresendelse og sikkerhedsgrupper, derefter den tilknyttede rutetabel. Hver har et tydeligt symptom, og gætteri springer den over, der faktisk er forkert.

Tilbagerulning vender samme rækkefølge om. Fjern arbejdsbyrde-undernettets rute sidst, efter du har gendannet de tidligere selectorer, så du ikke efterlader et undernet, der peger på en gateway, som ikke længere beskytter dets kilder. Selvhosting kan tjene mere end gateway-værten, når disse kontrakter holder, og AWS-administreret Site-to-Site VPN er en anden driftsmodel, hvor strongSwan i stedet kan sidde på kundegateway-siden.