strongSwan sa EC2: hayaang i-route ng VPC ang workload

Buhay ang tunnel, kayang i-ping ng gateway instance ang remote network, at hindi maabot ng katabing application instance ang kahit ano. Walang sira. Nagsimula ang tagumpay na pagsubok sa VPN host, at hindi nito kailanman itinanong kung kayang magdala ng ibang source address ang host na iyon sa parehong relasyong IPsec. Sinasara ng runbook na ito ang puwang na iyon sa apat na hakbang, sa pagkakasunod-sunod na nagpapanatiling nakikita ang bawat pagpalya.

Isulat muna ang apat na address

Tinutukoy ng bawat hakbang sa ibaba ang mga ito, kaya punan ang mga ito para sa sarili mong account bago hawakan ang isang routing table.

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

Ipinagpapalagay ng halimbawa ang isang aprubado at gumaganang koneksyong IPsec na nakabatay sa patakaran, at isang daloy na nagpapanatili ng pinagmulan. Hindi ito isang NAT na kliyente ng remote access na nanghihiram ng isang itinalagang address, at ang pagkakaibang iyon ang nagtatakda kung kailangang baguhin ang mga selector.

Hakbang 1: bigyan ng ruta ang subnet ng workload

Ang routing table na aktwal na nakaugnay sa subnet ng workload ay nangangailangan ng landas para sa remote prefix na tumuturo sa network interface ng gateway. Ang rutang bisita na inilagay sa loob ng instance ay hindi entry sa routing table ng AWS, at walang dami ng konfigurasyon ng strongSwan ang lilikha nito.

Inilalarawan ng gabay ng AWS sa pag-route sa pamamagitan ng appliance ang mga target na network interface at ang pangangailangan ng source/destination check ng instance na nagpapasa. Ilimita ang pagbabagong iyon sa check sa papel ng gateway, at hayaan ang mga ordinaryong application instance.

Huwag palitan ang lokal na ruta ng VPC o bawat umiiral na entry para magbigay ng puwang sa isang aprubadong network. Suriin kung ano ang nakaugnay at aktibo, hindi kung ano ang ipinapakita ng console page para sa routing table na walang gumagamit. Ang dalawang table na magkamukha ay maaaring may magkaibang ugnayan. Ang mahalaga ay ang table kung saan nakakabit ang subnet ng workload.

Hakbang 2: paganahin ang pagpapasa sa bisita

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

Kailangang magpasa ng kernel at kailangang pahintulutan ng firewall ng host ang pagdaan. Idagdag ang mga inaasahang panuntunan sa pagpapasa para sa workload at remote prefix sa halip na tanggapin ang lahat, at kumpirmahin na ang gateway subnet ay may nananatiling magagamit na transport route para sa sarili nitong trapiko.

Ang mga security group ang lugar kung saan kadalasang natigil ang hakbang na ito. Hindi namamana ng middlebox ang pag-uugali ng sanggunian ng security group ng direktang komunikasyon ng instance, kaya ang panuntunang kinopya mula sa halimbawa ng pinamamahalaang Client VPN ay maaaring hindi kailanman tumugma. Suriin ang security group at subnet ACL sa aktwal na landas, sa dalawang direksyon.

Hakbang 3: palawakin ang mga selector sa tunay na pinagmulan

Ang patakarang sumasakop lamang sa 10.60.1.10/32 sa panig ng AWS ay nagpapaliwanag ng tagumpay na nagmula sa gateway nang hindi sinasakop ang 10.60.2.20. Ang ruta patungo sa remote destination ay hindi nagpapalawak ng traffic selector, at iyon ang ikalawang kalahati ng parehong sorpresa.

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

Kung pinoprotektahan ng napagkasunduang disenyo ang buong VPC, dapat tanggapin ng parehong peer ang 10.60.0.0/16 at 10.90.0.0/24. Kung pinoprotektahan nito ang isang workload, gamitin nang sinasadya ang mas makitid na prefix. Sa anumang kaso, suriin ang naka-install na patakarang CHILD-SA, dahil ang konfigurasyong in-edit mo at ang peer na nagpaliit nito nang iba ay hindi ang parehong kasunduan.

Kailangan ding i-route ng remote site ang mga tugon para sa mga pinanatiling VPC source pabalik sa inaasahang IPsec gateway. Panatilihin ang sinusuportahang exemption ng NAT para sa protektadong trapiko kung saan may iba pang panuntunan ng source NAT; ang pagsasalin ng hindi aprubadong workload sa isang pinapayagang host address ay ibang kontrata ng pagkakakilanlan, hindi shortcut sa access na gusto mo.

Hakbang 4: i-verify, at kung kailangan ay i-roll back

Subukan mula sa workload mismo gamit ang bagong pinapayagang operasyon ng application, at pagkatapos ay ulitin sa destinasyong dapat ibukod. Itala ang source address na nakikita ng remote service at ang return path na ginagamit nito. Ang ping sa gateway o berdeng IKE status ay hindi ang pagsubok na iyon.

Kung nabibigo pa rin ang workload habang gumagana ang gateway, bumalik sa mga hakbang ayon sa pagkakasunod-sunod: selector, pagkatapos ay pagpapasa at mga security group, pagkatapos ay ang nakaugnay na routing table. Bawat isa ay may kakaibang sintomas, at ang hula ay lumalaktaw sa talagang mali.

Binabaligtad ng rollback ang parehong pagkakasunod-sunod. Alisin ang ruta ng subnet ng workload sa huli, pagkatapos maibalik ang mga dating selector, upang hindi mag-iwan ng subnet na tumuturo sa gateway na hindi na nagpoprotekta sa mga pinagmulan nito. Ang self-hosting ay makapaglilingkod nang higit sa gateway host kapag nananatili ang mga kontratang ito, at ang Site-to-Site VPN na pinamamahalaan ng AWS ay ibang modelong pang-operasyon kung saan ang strongSwan ay maaaring nasa dulo ng customer gateway sa halip.