strongSwan kwenye EC2: iachie VPC ielekeze mzigo wa kazi

Handaki iko juu, instance ya lango inaweza kupiga ping kwenye mtandao wa mbali, na instance ya programu iliyo karibu haiwezi kufikia chochote. Hakuna kilichovunjika. Jaribio lililofanikiwa lilianzia kwenye host ya VPN, na halikuwahi kuuliza kama host hiyo inaweza kubeba anwani nyingine ya chanzo kupitia uhusiano huo huo wa IPsec. Kitabu hiki cha uendeshaji hufunga pengo hilo kwa hatua nne, kwa mpangilio unaoweka kila kosa lionekane.

Kwanza andika anwani nne

Kila hatua hapa chini inarejelea hizi, kwa hivyo zijaze kwa akaunti yako mwenyewe kabla ya kugusa jedwali la njia.

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

Mfano unadhani muunganisho wa IPsec unaotegemea sera ulioidhinishwa na unaofanya kazi, na mtiririko unaohifadhi chanzo. Hii si mteja wa ufikiaji wa mbali wa NAT anayekopa anwani moja iliyotengwa, na tofauti hiyo huamua kama viteuzi vinapaswa kubadilika.

Hatua 1: ipe subineti ya mzigo wa kazi njia

Jedwali la njia linalohusishwa kwa kweli na subineti ya mzigo wa kazi linahitaji njia ya kiambishi cha mbali kinachoelekeza kwenye kiolesura cha mtandao cha lango. Njia ya mgeni iliyosakinishwa ndani ya instance si ingizo katika jedwali hilo la njia la AWS, na hakuna kiasi cha usanidi wa strongSwan kitakachounda moja.

Mwongozo wa AWS wa uelekezaji kupitia kifaa unaeleza malengo ya kiolesura cha mtandao na hitaji la ukaguzi wa chanzo/mwisho wa instance inayopeleka. Punguza mabadiliko hayo ya ukaguzi kwa jukumu la lango, na uache instance za kawaida za programu zikiwa tulivu.

Usibadilishe njia ya ndani ya VPC au kila ingizo lililopo ili kufanya nafasi kwa mtandao mmoja ulioidhinishwa. Chunguza kile kilichounganishwa na kinachofanya kazi, badala ya kile ukurasa wa konsoli unaonyesha kwa jedwali la njia ambalo hakuna anayetumia. Majedwali mawili yanayofanana yanaweza kuwa na miunganisho tofauti. Lile la muhimu ni lile ambalo subineti ya mzigo wa kazi imeunganishwa nalo.

Hatua 2: washa upelekaji kwenye mgeni

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

Kernel lazima ipeleke, na firewall ya host lazima iruhusu upitishaji. Ongeza kanuni za upelekaji zilizokusudiwa kwa viambishi vya mzigo wa kazi na vya mbali badala ya kukubali kila kitu, na thibitisha kuwa subineti ya lango inahifadhi njia ya usafirishaji inayoweza kutumika kwa trafiki yake yenyewe.

Vikundi vya usalama ndiko hatua hii kwa kawaida inakwama. Kifaa cha kati hakirithi tabia ya marejeleo ya kikundi cha usalama ya mawasiliano ya moja kwa moja ya instance, kwa hivyo kanuni iliyonakiliwa kutoka kwa mfano wa Client VPN inayosimamiwa inaweza isilingane kamwe. Angalia kikundi cha usalama na ACL ya subineti kwenye njia halisi, pande zote mbili.

Hatua 3: panua viteuzi hadi vyanzo halisi

Sera inayoshughulikia 10.60.1.10/32 pekee upande wa AWS inaeleza mafanikio yaliyoanzia kwenye lango bila kushughulikia 10.60.2.20. Njia kuelekea mwisho wa mbali haipanui kiteuzi cha trafiki, na hiyo ni nusu ya pili ya mshangao huo huo.

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

Ikiwa muundo uliokubaliwa unalinda VPC nzima, pande zote mbili lazima zikubali 10.60.0.0/16 na 10.90.0.0/24. Ikiwa unalinda mzigo mmoja wa kazi, tumia kwa makusudi kiambishi hicho chembamba. Kwa vyovyote vile, chunguza sera ya CHILD-SA iliyosakinishwa, kwa sababu usanidi uliouhariri na upande ulioupunguza kwa njia nyingine si makubaliano yale yale.

Eneo la mbali lazima pia lielekeze majibu ya vyanzo vya VPC vilivyohifadhiwa kurudi kupitia lango la IPsec lililokusudiwa. Hifadhi msamaha wa NAT unaotumika kwa trafiki iliyolindwa pale ambapo kuna kanuni nyingine za NAT ya chanzo; kutafsiri mzigo wa kazi ambao haujaizwa kuwa anwani ya host inayoruhusiwa ni mkataba mwingine wa utambulisho, si njia ya mkato kuelekea ufikiaji ulioutaka.

Hatua 4: thibitisha, kisha rudi nyuma ikibidi

Jaribu kutoka kwa mzigo wa kazi wenyewe kwa operesheni mpya ya programu inayoruhusiwa, kisha rudia na mwisho ambao unapaswa kuachwa nje. Andika anwani ya chanzo ambayo huduma ya mbali inaiona na njia ya kurudi inayotumika. Ping ya lango au hali ya IKE ya kijani si jaribio hilo.

Ikiwa mzigo wa kazi bado unashindikana wakati lango linafanya kazi, rudi nyuma kupitia hatua kwa mpangilio: kiteuzi, kisha upelekaji na vikundi vya usalama, kisha jedwali la njia linalohusishwa. Kila moja lina dalili tofauti, na kukisia kunakosa lile ambalo kwa kweli ni kosa.

Kurudi nyuma kunabadilisha mpangilio huo huo. Ondoa njia ya subineti ya mzigo wa kazi mwisho, baada ya kurejesha viteuzi vya awali, ili usiache subineti inayoelekeza kwenye lango ambalo haliendelei kulinda vyanzo vyake. Kujihifadhi kunaweza kuhudumia zaidi ya host ya lango wakati mikataba hii inashikilia, na Site-to-Site VPN inayosimamiwa na AWS ni mtindo mwingine wa uendeshaji ambapo strongSwan inaweza kukaa upande wa lango la mteja badala yake.