strongSwan në EC2: lëre VPC-në të drejtojë ngarkesën e punës

Tuneli është aktiv, instanca e portës mund të pingojë rrjetin e largët, ndërsa instanca e aplikacionit pranë saj nuk arrin asgjë. Asgjë nuk është prishur. Testi që doli me sukses nisi në hostin VPN dhe nuk pyeti kurrë nëse ai host mund të mbante një adresë tjetër burimore përmes të njëjtit raport IPsec. Ky manual e mbyll atë boshllëk në katër hapa, në rendin që mban çdo dështim të dukshëm.

Fillimisht shkruaj katër adresat

Çdo hap më poshtë u referohet këtyre, prandaj plotësoji për llogarinë tënde përpara se të prekësh një tabelë rrugëtimi.

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

Shembulli supozon një lidhje IPsec të miratuar e funksionale të bazuar në politika, dhe një rrjedhë që ruan burimin. Ky nuk është një klient aksesi të largët me NAT që huazon një adresë të caktuar, dhe ky ndryshim përcakton nëse selektorët duhet të ndryshojnë.

Hapi 1: jepi një rrugë nënrrjetit të ngarkesës së punës

Tabela e rrugëtimit që është në të vërtetë e lidhur me nënrrjetin e ngarkesës ka nevojë për një shteg për prefiksin e largët që tregon ndërfaqen e rrjetit të portës. Një rrugë mysafiri e instaluar brenda instancës nuk është një zë në atë tabelë rrugëtimi AWS, dhe asnjë sasi konfigurimi strongSwan nuk do të krijojë një.

Udhëzimet e AWS për rrugëtim përmes pajisjes përshkruajnë objektivat e ndërfaqes së rrjetit dhe kërkesën e verifikimit burim/destinacion të instancës që përcjell. Kufizoje atë ndryshim verifikimi te roli i portës dhe lëri instancat e zakonshme të aplikacionit në qetësi.

Mos e zëvendëso rrugën lokale të VPC-së ose çdo zë ekzistues për t'i bërë vend një rrjeti të miratuar. Inspekto çfarë është e lidhur dhe aktive, jo çfarë tregon një faqe konsoli për një tabelë rrugëtimi që askush nuk e përdor. Dy tabela që duken njësoj mund të kenë lidhje të ndryshme. Ajo që ka rëndësi është ajo ku është i lidhur nënrrjeti i ngarkesës.

Hapi 2: aktivizo përcjelljen te mysafiri

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

Kerneli duhet të përcjellë dhe muri i zjarrit i hostit duhet të lejojë tranzitin. Shto rregullat e synuara të përcjelljes për prefikset e ngarkesës dhe të largëta në vend që të pranosh gjithçka, dhe konfirmo që nënrrjeti i portës mban një rrugë transporti të përdorshme për trafikun e vet.

Grupet e sigurisë janë vendi ku ky hap zakonisht ngec. Një pajisje ndërmjetëse nuk trashëgon sjelljen e referencës së grupeve të sigurisë të komunikimit të drejtpërdrejtë mes instancave, prandaj një rregull i kopjuar nga një shembull Client VPN i menaxhuar mund të mos përputhet kurrë. Kontrollo grupin e sigurisë dhe ACL-në e nënrrjetit në shtegun real, në të dy drejtimet.

Hapi 3: zgjero selektorët te burimet reale

Një politikë që mbulon vetëm 10.60.1.10/32 në anën e AWS shpjegon një sukses që nisi në portë pa mbuluar 10.60.2.20. Një rrugë drejt destinacionit të largët nuk zgjeron një selektor trafiku, dhe kjo është gjysma e dytë e së njëjtës befasi.

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

Nëse dizajni i rënë dakord mbron të gjithë VPC-në, të dy partnerët duhet të pranojnë 10.60.0.0/16 dhe 10.90.0.0/24. Nëse mbron një ngarkesë të vetme, përdore me qëllim atë prefiks më të ngushtë. Në çdo rast, inspekto politikën CHILD-SA të instaluar, sepse një konfigurim që ke redaktuar dhe një palë që e ka ngushtuar ndryshe nuk janë i njëjti marrëveshje.

Vendndodhja e largët duhet gjithashtu të drejtojë përgjigjet për burimet e VPC-së të ruajtura përsëri përmes portës IPsec të synuar. Mbaj përjashtimin e NAT-it të mbështetur për trafikun e mbrojtur aty ku ekzistojnë rregulla të tjera NAT burimi; përkthimi i një ngarkese të pa miratuar në një adresë hosti të lejuar është një kontratë tjetër identiteti, jo një shkurtore drejt aksesit që dëshiroje.

Hapi 4: verifiko, pastaj kthehu mbrapsht nëse duhet

Testo nga vetë ngarkesa me një operacion të ri aplikacioni të lejuar, pastaj përsërite me një destinacion që duhet të përjashtohet. Shëno adresën burimore që sheh shërbimi i largët dhe shtegun e kthimit që përdor. Një ping porte ose një status IKE i gjelbër nuk është ai test.

Nëse ngarkesa vazhdon të dështojë ndërsa porta funksionon, kthehu mbrapsht nëpër hapat sipas rendit: selektor, pastaj përcjellje dhe grupe sigurie, pastaj tabela e rrugëtimit e lidhur. Secili ka një simptomë të veçantë, dhe hamendja kalon përtej atij që është vërtet i gabuar.

Kthimi mbrapsht përmbys të njëjtin rend. Hiqe rrugën e nënrrjetit të ngarkesës së fundit, pasi të kesh rikthyer selektorët e mëparshëm, që të mos lësh një nënrrjet që tregon një portë që nuk i mbron më burimet e tij. Vetëstrehimi mund të shërbejë më shumë se hosti i portës kur këto kontrata qëndrojnë, dhe Site-to-Site VPN i menaxhuar nga AWS është një model tjetër operimi ku strongSwan mund të ulet në skajin e portës së klientit.