strongSwan på EC2: la VPC-en rute arbeidslasten

Tunnelen er oppe, gateway-instansen kan pinge det eksterne nettverket, og applikasjonsinstansen ved siden av når ingenting. Ingenting er ødelagt. Testen som lyktes, startet på VPN-vertet, og den spurte aldri om det vertet kunne bære en annen kildeadresse gjennom det samme IPsec-forholdet. Denne kjøreboken lukker det gapet i fire trinn, i den rekkefølgen som holder hver feil synlig.

Skriv ned de fire adressene først

Hvert trinn nedenfor viser til disse, så fyll dem ut for din egen konto før du rører en rutetabell.

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

Eksempelet forutsetter en godkjent, fungerende policybasert IPsec-tilkobling og en strøm som bevarer kilden. Dette er ikke en NAT-et fjernklient som låner én tildelt adresse, og den forskjellen avgjør om selektorene må endres.

Trinn 1: gi arbeidslast-subnettet en rute

Rutetabellen som faktisk er knyttet til arbeidslast-subnettet, trenger en sti for det eksterne prefikset som peker på gatewayens nettverksgrensesnitt. En gjesterute installert inne i instansen er ikke en oppføring i den AWS-rutetabellen, og ingen mengde strongSwan-konfigurasjon vil opprette en.

AWS' veiledning for ruting via apparat beskriver nettverksgrensesnitt-mål og kravet om kilde-/destinasjonskontroll for instansen som videresender. Begrens den kontrollendringen til gateway-rollen, og la vanlige applikasjonsinstanser være i fred.

Ikke erstatt VPC-ens lokale rute eller hver eksisterende oppføring for å gjøre plass til ett godkjent nettverk. Undersøk hva som er knyttet til og aktivt, i stedet for hva en konsollside viser for en rutetabell ingen bruker. To tabeller som ser like ut kan ha ulike tilknytninger. Den som betyr noe, er den arbeidslast-subnettet er knyttet til.

Trinn 2: slå på videresending på gjesten

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

Kjernen må videresende, og vertens brannmur må tillate gjennomgangen. Legg til de tiltenkte videresendingsreglene for arbeidslast- og eksterne prefikser i stedet for å godta alt, og bekreft at gateway-subnettet beholder en brukbar transportrute for sin egen trafikk.

Sikkerhetsgrupper er der dette trinnet vanligvis stopper. En mellomapparat arver ikke sikkerhetsgruppe-referanseatferden fra direkte instanskommunikasjon, så en regel kopiert fra et administrert Client VPN-eksempel vil kanskje aldri stemme. Kontroller sikkerhetsgruppen og subnett-ACL-en på den faktiske stien, i begge retninger.

Trinn 3: utvid selektorene til de virkelige kildene

En policy som bare dekker 10.60.1.10/32 på AWS-siden forklarer en suksess som oppsto på gatewayen, uten å dekke 10.60.2.20. En rute mot den eksterne destinasjonen utvider ikke en trafikkselektor, og det er den andre halvdelen av den samme overraskelsen.

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

Hvis det avtalte designet beskytter hele VPC-en, må begge parter godta 10.60.0.0/16 og 10.90.0.0/24. Hvis det beskytter én arbeidslast, bruk det smalere prefikset bevisst. Uansett, undersøk den installerte CHILD-SA-policyen, for en konfigurasjon du har redigert og en part som har snevret den inn annerledes, er ikke den samme avtalen.

Det eksterne stedet må også rute svar for de bevarede VPC-kildene tilbake gjennom den tiltenkte IPsec-gatewayen. Behold den støttede NAT-fritakelsen for beskyttet trafikk der andre kilde-NAT-regler finnes; å oversette en ikke-godkjent arbeidslast til en tillatt vertsadresse er en annen identitetskontrakt, ikke en snarvei til tilgangen du ønsket.

Trinn 4: verifiser, og rull deretter tilbake om nødvendig

Test fra selve arbeidslasten med en ny tillatt applikasjonsoperasjon, og gjenta deretter med en destinasjon som bør utelukkes. Noter kildeadressen den eksterne tjenesten ser, og returveien den bruker. En gateway-ping eller en grønn IKE-status er ikke den testen.

Hvis arbeidslasten fortsatt feiler mens gatewayen virker, gå tilbake gjennom trinnene i rekkefølge: selektor, deretter videresending og sikkerhetsgrupper, deretter den tilknyttede rutetabellen. Hver har et tydelig symptom, og gjetting hopper over den som faktisk er feil.

Tilbakerullingen reverserer samme rekkefølge. Fjern ruten til arbeidslast-subnettet sist, etter at du har gjenopprettet de forrige selektorene, så du ikke etterlater et subnett som peker på en gateway som ikke lenger beskytter kildene. Egen hosting kan tjene mer enn gateway-verten når disse kontraktene holder, og AWS-administrert Site-to-Site VPN er en annen driftsmodell der strongSwan i stedet kan sitte på kundegateway-siden.