strongSwan uz EC2: ļaujiet VPC maršrutēt darba slodzi

No vārtejas strādājošs tunelis pierāda tikai vārteju. Maršrutējiet darba slodzes apakštīklu, ieslēdziet pāradresāciju viesī, paplašiniet selektorus un pēc tam pārbaudiet no tā.

Tunelis ir aktīvs, vārtejas instance var pingot attālo tīklu, un blakus esošā lietojumprogrammas instance neko nesasniedz. Nekas nav salūzis. Veiksmīgais tests sākās VPN resursdatorā, un tas nekad nejautāja, vai šis resursdators var pārvadāt citu avota adresi caur to pašu IPsec saistību. Šī rokasgrāmata aizver šo plaisu četros soļos, tādā secībā, kas katru kļūmi saglabā redzamu.

Vispirms pierakstiet četras adreses

Katrs turpmākais solis uz tām atsaucas, tāpēc aizpildiet tās savam kontam, pirms aiztiekat maršrutēšanas tabulu.

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

Piemērs pieņem apstiprinātu, strādājošu uz politikas balstītu IPsec savienojumu un avotu saglabājošu plūsmu. Tas nav NAT'ots attālās piekļuves klients, kas aizņemas vienu piešķirtu adresi, un šī atšķirība izšķir, vai selektori ir jāmaina.

1. solis: piešķiriet darba slodzes apakštīklam maršrutu

Maršrutēšanas tabulai, kas faktiski ir saistīta ar darba slodzes apakštīklu, ir vajadzīgs ceļš uz attālo prefiksu, kas norāda uz vārtejas tīkla saskarni. Instances iekšienē instalēts viesa maršruts nav ieraksts šajā AWS maršrutēšanas tabulā, un nekāda strongSwan konfigurācija to neizveidos.

AWS norādījumi par maršrutēšanu caur ierīci apraksta tīkla saskarnes mērķus un pāradresējošās instances avota/galamērķa pārbaudes prasību. Ierobežojiet šo pārbaudes izmaiņu ar vārtejas lomu un atstājiet parastās lietojumprogrammu instances mierā.

Neaizstājiet VPC lokālo maršrutu vai katru esošo ierakstu, lai atbrīvotu vietu vienam apstiprinātam tīklam. Pārbaudiet, kas ir saistīts un aktīvs, nevis to, ko konsoles lapa rāda maršrutēšanas tabulai, kuru neviens neizmanto. Divām līdzīgām tabulām var būt atšķirīgas saistības. Svarīgā ir tā, kurai ir pievienots darba slodzes apakštīkls.

2. solis: ieslēdziet pāradresāciju viesī

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

Kodolam ir jāpāradresē, un resursdatora ugunsmūrim jāatļauj tranzīts. Pievienojiet paredzētos pāradresēšanas noteikumus darba slodzes un attālajiem prefiksiem, nevis pieņemiet visu, un apstipriniet, ka vārtejas apakštīkls saglabā izmantojamu transporta maršrutu savam paša trafikam.

Drošības grupas ir vieta, kur šis solis parasti apstājas. Starpierīce nemanto tiešas instanču komunikācijas drošības grupas atsauces uzvedību, tāpēc noteikums, kas nokopēts no pārvaldīta Client VPN piemēra, var nekad nesakrist. Pārbaudiet drošības grupu un apakštīkla ACL faktiskajā ceļā, abos virzienos.

3. solis: paplašiniet selektorus uz īstajiem avotiem

Politika, kas AWS pusē aptver tikai 10.60.1.10/32, izskaidro no vārtejas izcēlušos panākumus, neaptverot 10.60.2.20. Maršruts uz attālo galamērķi nepaplašina trafika selektoru, un tā ir tā paša pārsteiguma otrā puse.

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

Ja saskaņotais dizains aizsargā visu VPC, abām pusēm jāpieņem 10.60.0.0/16 un 10.90.0.0/24. Ja tas aizsargā vienu darba slodzi, apzināti izmantojiet šo šaurāko prefiksu. Jebkurā gadījumā pārbaudiet instalēto CHILD-SA politiku, jo konfigurācija, ko jūs rediģējāt, un puse, kas to sašaurināja citādi, nav tas pats līgums.

Attālajai vietai arī jāmaršrutē atbildes saglabātajiem VPC avotiem atpakaļ caur paredzēto IPsec vārteju. Saglabājiet atbalstīto NAT izņēmumu aizsargātajam trafikam tur, kur pastāv citi avota NAT noteikumi; neapstiprinātas darba slodzes pārtulkošana atļautā resursdatora adresē ir cits identitātes līgums, nevis saīsne uz vēlamo piekļuvi.

4. solis: pārbaudiet un, ja nepieciešams, atritiniet atpakaļ

Pārbaudiet no pašas darba slodzes ar jaunu atļautu lietojumprogrammas darbību, pēc tam atkārtojiet ar galamērķi, kas būtu jāizslēdz. Pierakstiet avota adresi, ko redz attālais pakalpojums, un atgriešanās ceļu, ko tas izmanto. Vārtejas ping vai zaļš IKE statuss nav šis tests.

Ja darba slodze joprojām neizdodas, kamēr vārteja darbojas, ejiet atpakaļ pa soļiem secībā: selektors, tad pāradresācija un drošības grupas, tad saistītā maršrutēšanas tabula. Katram ir atšķirīgs simptoms, un minēšana izlaiž to, kas patiešām ir nepareizs.

Atritināšana apgriež to pašu secību. Noņemiet darba slodzes apakštīkla maršrutu pēdējo, pēc iepriekšējo selektoru atjaunošanas, lai nepaliktu apakštīkls, kas norāda uz vārteju, kura vairs neaizsargā tā avotus. Pašhostinga gadījumā var apkalpot vairāk nekā vārtejas resursdatoru, ja šie līgumi ir spēkā, un AWS pārvaldītais Site-to-Site VPN ir cits darbības modelis, kur strongSwan var atrasties klienta vārtejas pusē.

Saistītie raksti