strongSwan på EC2: la VPC-en rute arbeidslasta

Tunnelen er oppe, gateway-instansen kan pinga det eksterne nettet, og applikasjonsinstansen ved sida av når ingenting. Ingenting er øydelagt. Testen som lukkast, starta på VPN-verten, og han spurde aldri om den verten kunne bera ei anna kjeldeadresse gjennom det same IPsec-tilhøvet. Denne køyreboka lukkar det gapet i fire steg, i den rekkjefølgja som held kvar feil synleg.

Skriv ned dei fire adressene fyrst

Kvart steg nedanfor viser til desse, so fyll dei ut for din eigen konto før du rører ei 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

Dømet føreset ei godkjend, fungerande policybasert IPsec-tilkopling og ein straum som bevarer kjelda. Dette er ikkje ein NAT-a fjernklient som låner éi tildelt adresse, og den skilnaden avgjer om selektorane må endrast.

Steg 1: gje arbeidslast-subnettet ei rute

Rutetabellen som faktisk er knytt til arbeidslast-subnettet, treng ein sti for det eksterne prefikset som peikar på nettverksgrensesnittet til gatewayen. Ei gjesterute installert inne i instansen er ikkje ei oppføring i den AWS-rutetabellen, og inga mengd strongSwan-konfigurasjon vil oppretta ei.

AWS sine rettleiar for ruting via apparat skildrar nettverksgrensesnitt-mål og kravet om kjelde-/målkontroll for instansen som vidaresender. Avgrens den kontrollendringa til gateway-rolla, og lat vanlege applikasjonsinstansar vera i fred.

Ikkje erstatt den lokale ruta til VPC-en eller kvar eksisterande oppføring for å gjera plass til eitt godkjent nettverk. Gransk kva som er knytt til og aktivt, i staden for kva ei konsollside viser for ein rutetabell ingen brukar. To tabellar som ser like ut kan ha ulike tilknytingar. Den som gjeld, er den arbeidslast-subnettet er knytt til.

Steg 2: slå på vidaresending på gjesten

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

Kjernen må vidaresenda, og brannmuren på verten må tillate gjennomgangen. Legg til dei tiltenkte vidaresendingsreglane for arbeidslast- og eksterne prefiks i staden for å godta alt, og stadfest at gateway-subnettet held på ei brukande transportrute for sin eigen trafikk.

Tryggingsgrupper er der dette steget vanlegvis stoppar. Eit mellomapparat arvar ikkje tryggingsgruppe-referanseåtferda frå direkte instanskommunikasjon, so ein regel kopiert frå eit døme på administrert Client VPN vil kanskje aldri stemma. Kontroller tryggingsgruppa og subnett-ACL-en på den faktiske stien, i båe retningar.

Steg 3: utvid selektorane til dei verkelege kjeldene

Ein policy som berre dekkjer 10.60.1.10/32 på AWS-sida forklarar ein suksess som oppstod på gatewayen, utan å dekkja 10.60.2.20. Ei rute mot den eksterne destinasjonen utvidar ikkje ein trafikkselektor, og det er den andre halvdelen av den same overraskinga.

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

Viss designet ein er samde om vernar heile VPC-en, må båe partar godta 10.60.0.0/16 og 10.90.0.0/24. Viss det vernar éi arbeidslast, bruk det smalare prefikset med vilje. Uansett, gransk den installerte CHILD-SA-policyen, for ein konfigurasjon du har redigert og ein part som har snevra han inn annleis, er ikkje den same avtalen.

Den eksterne staden må òg rute svar for dei bevarde VPC-kjeldene tilbake gjennom den tiltenkte IPsec-gatewayen. Hald på den støtta NAT-fritakinga for verna trafikk der andre kjelde-NAT-reglar finst; å omsetja ei ikkje-godkjend arbeidslast til ei tillaten vertsadresse er ein annan identitetskontrakt, ikkje ein snøggveg til tilgangen du ønskte.

Steg 4: verifiser, og rull deretter tilbake om naudsynt

Test frå sjølve arbeidslasta med ein ny tillaten applikasjonsoperasjon, og gjer det så om att med ein destinasjon som bør utelukkast. Noter kjeldeadressa den eksterne tenesta ser, og returvegen ho brukar. Ein gateway-ping eller ein grøn IKE-status er ikkje den testen.

Viss arbeidslasta framleis feilar medan gatewayen verkar, gå tilbake gjennom stega i rekkjefølgje: selektor, deretter vidaresending og tryggingsgrupper, deretter den tilknytte rutetabellen. Kvar har eit tydeleg symptom, og gjetting hoppar over den som faktisk er feil.

Tilbakerullinga snur den same rekkjefølgja. Fjern ruta til arbeidslast-subnettet sist, etter at du har gjenoppretta dei førre selektorane, so du ikkje lèt att eit subnett som peikar på ein gateway som ikkje lenger vernar kjeldene. Eigen hosting kan tena meir enn gateway-verten når desse kontraktane held, og AWS-administrert Site-to-Site VPN er ein annan driftsmodell der strongSwan i staden kan sitja på kundegateway-sida.