strongSwan EC2-n: VPC-k karga bidera dezan

Atebide batetik dabilen tunel batek atebidea baino ez du frogatzen. Bideratu kargaren azpisarea, gaitu birbidalketa gonbidatuan, zabaldu hautatzaileak eta gero egin proba handik.

Tunela martxan dago, atebidearen instantziak urruneko sarera ping egin dezake, eta ondoan dagoen aplikazioaren instantziak ezin du ezerra iritsi. Ez dago ezer hautsita. Arrakasta izan zuen proba VPN ostalarian hasi zen, eta ez zuen inoiz galdetu ostalari hark beste iturburu-helbide bat eraman zezakeenik IPsec harreman beretik. Runbook honek hutsune hori lau urratsetan ixten du, hutsegite bakoitza ikusgai mantentzen duen ordenean.

Idatzi lehenengo lau helbideak

Hurrengo urrats bakoitzak hauei egiten die erreferentzia, beraz bete itzazu zure konturako bideratze-taulari heldu aurretik.

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

Adibideak onartutako eta funtzionatzen duen politika-oinarriko IPsec konexio bat eta iturburua mantentzen duen fluxu bat suposatzen ditu. Hau ez da helbide esleitu bat maileguan hartzen duen NAT bidezko urruneko sarbide bezeroa, eta alde horrek erabakitzen du hautatzaileek aldatu behar duten.

1. urratsa: eman bidea kargaren azpiseari

Kargaren azpisareari benetan lotuta dagoen bideratze-taulak atebidearen sare-interfazea seinalatzen duen bidea behar du urruneko aurrizkirako. Instantziaren barruan instalatutako gonbidatu-bide bat ez da AWS bideratze-taulako sarrera, eta strongSwan konfigurazioak ez du inoiz halakorik sortuko.

AWS-en gailu bidezko bideratze-gidak sare-interfazearen helburuak eta birbidaltzen duen instantziaren iturburu/helmuga egiaztapenaren baldintza deskribatzen ditu. Mugatu egiaztapen-aldaketa hori atebidearen rolari, eta utzi aplikazio-instantzia arruntak bakean.

Ez ordeztu VPCren bide lokala ezta lehendik dagoen sarrera guztiak sare onartu batentzako lekua egiteko. Aztertu zer dagoen lotuta eta aktibo, inork erabiltzen ez duen bideratze-taulari buruz kontsolako orri batek erakusten duenaren ordez. Antzekoak diruditen bi taulaek lotura desberdinak izan ditzakete. Garrantzitsuena kargaren azpisarea lotuta dagoen hura da.

2. urratsa: gaitu birbidalketa gonbidatuan

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

Kernelak birbidali behar du, eta ostalariaren suebakiak igarotzea baimendu behar du. Gehitu kargaren eta urruneko aurrizkien aurreikusitako birbidalketa-arauak dena onartu beharrean, eta berretsi atebidearen azpisareak bere trafikoarako garraio-bide erabilgarri bat mantentzen duela.

Segurtasun-taldeak dira urrats hau normalean trabatzen den lekua. Bitarteko gailu batek ez du instantzia arteko komunikazio zuzenaren segurtasun-talde erreferentzia-portaera heredatzen, beraz Client VPN kudeatu baten adibidetik kopiatutako arau bat inoiz ez dator bat. Egiaztatu segurtasun-taldea eta azpisareko ACL benetako bidean, bi noranzkoetan.

3. urratsa: zabaldu hautatzaileak benetako iturburuetara

AWS aldean 10.60.1.10/32 baino estaltzen ez duen politika batek atebidetik hasitako arrakasta azaltzen du 10.60.2.20 estali gabe. Urruneko helmugarako bide batek ez du trafiko-hautatzailerik zabaltzen, eta hori da ustekizun beraren bigarren erdia.

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

Adostutako diseinuak VPC osoa babesten badu, bi pareek 10.60.0.0/16 eta 10.90.0.0/24 onartu behar dituzte. Karga bat babesten badu, erabili nahita aurrizki estuago hori. Edonola ere, aztertu instalatutako CHILD-SA politika, zuk editatu duzun konfigurazioa eta beste modu batera estutu zuen pare bat ez baitira akordio bera.

Urruneko guneak ere bideratu behar ditu mantendutako VPC iturburuen erantzunak aurreikusitako IPsec atebidetik. Mantendu babestutako trafikoarentzako onartutako NAT salbuespena, beste iturburu-NAT arau batzuk dauden tokian; onartu gabeko karga bat ostalari-helbide baimendu bihurtzea beste identitate-kontratu bat da, ez nahi zenuen sarbiderako bide laburra.

4. urratsa: egiaztatu, eta behar izanez gero atzera egin

Probatu kargatik bertatik baimendutako aplikazio-eragiketa berri batekin, eta gero errepikatu kanpoan geratu behar lukeen helmuga batekin. Idatzi urruneko zerbitzuak ikusten duen iturburu-helbidea eta erabiltzen duen itzulera-bidea. Atebideari ping egitea edo IKE egoera berdea ez da proba hori.

Kargak oraindik huts egiten badu atebideak funtzionatzen duen bitartean, egin atzera urratsetan zehar ordenean: hautatzailea, gero birbidalketa eta segurtasun-taldeak, gero lotutako bideratze-taula. Bakoitzak sintoma desberdina du, eta asmatzeak benetan oker dagoena saltatzen du.

Atzera egiteak ordena bera alderantzikatzen du. Kendu kargaren azpisareko bidea azkenik, aurreko hautatzaileak berreskuratu ondoren, ez dezazun utzi iturburuak jada babesten ez dituen atebide batera seinalatzen duen azpisarerik. Norberaren ostatatzeak atebidearen ostalaria baino gehiagori zerbitzatu diezaioke kontratu hauek betetzen direnean, eta AWS-ek kudeatutako Site-to-Site VPN beste eragiketa-eredu bat da, non strongSwan bezeroaren atebidearen aldean egon daitekeen.

Erlazionatutako artikuluak