Tunelis veikia, tinklų sietuvos egzempliorius gali pinginti nuotolinį tinklą, o šalia esantis programos egzempliorius nieko nepasiekia. Niekas nesugedę. Sėkmingas testas prasidėjo VPN hoste, ir jis niekada neklausė, ar tas hostas gali perduoti kitą šaltinio adresą tuo pačiu IPsec ryšiu. Šis vadovas užveria šią spragą keturiais žingsniais, tokia tvarka, kuri kiekvieną gedimą palieka matomą.

Pirmiausia užsirašykite keturis adresus

Kiekvienas toliau pateiktas žingsnis remiasi jais, todėl užpildykite juos savo paskyrai prieš liesdami maršrutų lentelę.

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

Pavyzdys daro prielaidą, kad yra patvirtintas, veikiantis taisyklėmis pagrįstas IPsec ryšys ir šaltinį išlaikantis srautas. Tai nėra NAT'intas nuotolinės prieigos klientas, pasiskolinantis vieną priskirtą adresą, ir šis skirtumas lemia, ar reikia keisti selektorius.

1 žingsnis: suteikite darbo krūvio potinkliui maršrutą

Maršrutų lentelė, kuri iš tikrųjų susieta su darbo krūvio potinkliu, turi turėti kelią nuotoliniam prefiksui, nukreiptą į tinklų sietuvos tinklo sąsają. Egzemplioriaus viduje įdiegtas svečio maršrutas nėra įrašas toje AWS maršrutų lentelėje, ir jokia strongSwan konfigūracija jo nesukurs.

AWS rekomendacijos dėl maršrutizavimo per įrenginį aprašo tinklo sąsajos tikslus ir persiunčiančio egzemplioriaus šaltinio/paskirties tikrinimo reikalavimą. Apribokite šį tikrinimo pakeitimą tinklų sietuvos vaidmeniui ir palikite įprastus programos egzempliorius ramybėje.

Nepakeiskite VPC vietinio maršruto ar kiekvieno esamo įrašo, kad atlaisvintumėte vietos vienam patvirtintam tinklui. Tikrinkite, kas susieta ir aktyvu, o ne tai, ką konsolės puslapis rodo maršrutų lentelei, kurios niekas nenaudoja. Dvi panašiai atrodančios lentelės gali turėti skirtingus susiejimus. Svarbi yra ta, prie kurios prijungtas darbo krūvio potinklis.

2 žingsnis: įjunkite persiuntimą svečiame

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

Branduolys turi persiųsti, o hosto ugniasienė turi leisti tranzitą. Pridėkite numatytas persiuntimo taisykles darbo krūvio ir nuotoliniams prefiksams, o ne priimkite viską, ir patvirtinkite, kad tinklų sietuvos potinklis išlaiko naudojamą transporto maršrutą savo pačio srautui.

Saugos grupės yra vieta, kur šis žingsnis dažniausiai sustoja. Tarpinis įrenginys nepaveldi tiesioginio egzempliorių ryšio saugos grupės nuorodos elgsenos, todėl taisyklė, nukopijuota iš valdomo Client VPN pavyzdžio, gali niekada nesutapti. Patikrinkite saugos grupę ir potinklio ACL tikrajame kelyje, abiem kryptimis.

3 žingsnis: išplėskite selektorius iki tikrųjų šaltinių

Taisyklė, kuri AWS pusėje apima tik 10.60.1.10/32, paaiškina sėkmę, kilusią iš tinklų sietuvos, neapimdama 10.60.2.20. Maršrutas link nuotolinės paskirties neišplečia srauto selektoriaus, ir tai yra antroji tos pačios staigmenos pusė.

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

Jei sutartas projektas saugo visą VPC, abi pusės turi priimti 10.60.0.0/16 ir 10.90.0.0/24. Jei saugo vieną darbo krūvį, sąmoningai naudokite tą siauresnį prefiksą. Bet kuriuo atveju patikrinkite įdiegtą CHILD-SA taisyklę, nes konfigūracija, kurią redagavote, ir partneris, kuris ją susiaurino kitaip, nėra ta pati sutartis.

Nuotolinė vietovė taip pat turi maršrutizuoti atsakymus išsaugotiems VPC šaltiniams atgal per numatytą IPsec tinklų sietuvą. Išlaikykite palaikomą NAT išimtį apsaugotam srautui ten, kur yra kitų šaltinio NAT taisyklių; nepatvirtinto darbo krūvio pavertimas leidžiamu hosto adresu yra kita tapatybės sutartis, o ne trumpesnis kelias į norimą prieigą.

4 žingsnis: patikrinkite, o prireikus atsukite atgal

Išbandykite iš paties darbo krūvio nauja leidžiama programos operacija, tada pakartokite su paskirtimi, kuri turėtų būti neįtraukta. Užsirašykite šaltinio adresą, kurį mato nuotolinė paslauga, ir grįžtamąjį kelią, kurį ji naudoja. Tinklų sietuvos ping ar žalias IKE būsenas nėra tas testas.

Jei darbo krūvis vis tiek nepavyksta, kol tinklų sietuvas veikia, grįžkite per žingsnius iš eilės: selektorius, tada persiuntimas ir saugos grupės, tada susieta maršrutų lentelė. Kiekvienas turi skirtingą simptomą, o spėliojimas praleidžia tą, kuris iš tikrųjų neteisingas.

Atgalinis atsukimas apverčia tą pačią tvarką. Pašalinkite darbo krūvio potinklio maršrutą paskutinį, atkūrę ankstesnius selektorius, kad nepaliktumėte potinklio, nukreipto į tinklų sietuvą, kuri nebeteikia apsaugos jo šaltiniams. Savarankiškas hostinimas gali aptarnauti daugiau nei tinklų sietuvos hostą, kai šios sutartys galioja, o AWS valdomas Site-to-Site VPN yra kitas veikimo modelis, kuriame strongSwan gali būti kliento tinklų sietuvos pusėje.

Susiję straipsniai