Iš strongSwan į AWS Site-to-Site: kodėl Child SA nieko nepasirenka

IKE tunelis gali būti aktyvus, nors antrinė asociacija išskiria jūsų potinklius. Pirmiausia palyginkite AWS vietinį ir nuotolinį CIDR su leftsubnet ir rightsubnet.

Konsolė rodo up, strongSwan praneša apie nustatytą IKE asociaciją, o paketai vis tiek neatvyksta. Kitas dalykas, kurį reikia palyginti, yra ne iš anksto bendrinamas raktas, o priešdėlių pora, kurią kiekviena pusė mano esant apsaugotą tunelio. Atlikite toliau pateiktus patikrinimus iš eilės, nes pirmieji du nusprendžia, ar tunelis apskritai gali perduoti jūsų srautą.

Išverskite AWS pavadinimus į strongSwan terminus

AWS apibūdina ryšį iš kliento pusės: kliento šliuzo adresas ir vietinis CIDR priklauso jums, o nuotolinis CIDR priklauso VPC. strongSwan abu galus vadina left ir right, jūsų priešdėlis yra leftsubnet, o VPC priešdėlis – rightsubnet. Apvertus vieną porą gaunamas tunelis, kuris derasi dėl netinkamo srauto ir jį pasirenka.

Atsisiųskite konfigūraciją, kurią AWS sukuria ryšiui, ir laikykite ją būtent to ryšio atspirties tašku, įskaitant tunelio adresus ir priešdėlius. Jei kurdami abu CIDR laukus paliksite tuščius, paslauga naudos numatytąją 0.0.0.0/0 reikšmę kiekvienoje pusėje. Siauru priešdėliu sukonfigūruotas maršrutizatorius tada niekada nesutaps, todėl arba užpildykite laukus, arba sąmoningai praplėskite parinkiklį.

Neatitikimas čia atrodo kaip maršrutizavimo gedimas, bet juo nėra.

Užfiksuokite adresą, kurį AWS iš tikrųjų mato

Maršrutizatorius už NAT gali siųsti IKE iš sąsajos, apie kurią priešinga pusė niekada nesužinojo. AWS užrašytas šliuzo adresas turi būti tas, kurį AWS mato tinkle, o maršrutizatorius turi būti pritvirtintas prie to paties vietinio adreso, o ne sekti savo numatytuoju maršrutu.

conn %default
    local_addrs = 203.0.113.10

strongSwan atveju local_addrs parenka IKE šaltinio adresą, o senesnės OpenSwan konfigūracijos tą pačią idėją rašo kaip left. Nukreipkite jį į sąsają, turinčią viešąjį adresą, tada pačiame NAT įrenginyje patikrinkite, ar UDP 500 ir 4500 pasiekia tą hostą, nes iš ankstesnio maršrutizatoriaus likusi taisyklė juos tyliai numeta. Teisinga parinkiklių pora su neteisingu šaltinio adresu vis tiek nepavyksta, o žurnalas kaltins pasiūlymą. Būtent šis klaidinimas yra priežastis, kodėl šaltinio adresas nusipelno atskiro patikrinimo.

Patvirtinkite persiuntimo taisyklę, o ne darykite prielaidą, nes taisyklė, kuri buvo teisinga ankstesniam maršrutizatoriui, dažnai lieka.

1 ir 2 fazes nagrinėkite atskirai

AWS rodo IKE ir ESP parinktis kaip atskirus sąrašus. IKE rinkinys, kurį priima abi pusės, nieko nesako apie ESP pasiūlymą, nes šie sąrašai nepriklausomi. Perskaitykite abu iš sukurtos konfigūracijos ir palyginkite po vieną.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Sintaksė nekeliauja tarp implementacijų. Pora, kuri veikia OpenSwan, pavyzdžiui phase2alg=aes_gcm su ike=aes256-sha1;modp1024, turi būti išversta į strongSwan esp= ir ike= formą, o algoritmų pavadinimai skiriasi. Kadangi GCM autentifikuoja šifruodamas, jam nereikia atskiros vientisumo transformacijos, kitaip nei CBC rinkiniui su SHA. 2 fazės eilutė, įklijuota iš vieno demono į kitą be vertimo, sukelia atmetimą, kuris skaitomas kaip parinkiklių neatitikimas.

Tikrinkite antrinę asociaciją, o ne tunelio indikatorių

Jei ryšys įkeliamas, bet antrinė asociacija neatsiranda, buvo atmestas pasiūlymas arba parinkikliai. Jei antrinė atsiranda ir jos parinkikliai išskiria jūsų priešdėlius, paketai filtruojami dar nepasiekę tunelio. Konsolės indikatorius apima tik IKE lygį, todėl negali pasakyti, kuris iš dviejų įvyko.

ipsec statusall

Raskite antrinę saugos asociaciją ir perskaitykite šalia atspausdintus srauto parinkiklius, tada palyginkite juos su sukurtos konfigūracijos priešdėliais.

Išbandykite iš hosto vietiniame priešdėlyje į hostą VPC priešdėlyje ir patikrinkite grįžimo kelią bei bet kurią saugos grupę ar tinklo ACL AWS pusėje. Teisingi parinkikliai neapsaugo paketo nuo vėlesnio numetimo.

Kai vis tiek nepavyksta parinkikliams sutapus

Patvirtinkite, kad maršrutas abiejose pusėse veda į tunelį, tada patvirtinkite, kad NAT įrenginys neperrašo srauto taip, kaip politika nesitiki. Politika pagrįstas tunelis sutapatina paketų adresus, todėl po politiko sprendimo pritaikytas vertimas pakeičia rezultatą.

Užregistruokite po vieną įeinančią ir išeinančią paketą kiekvienoje pusėje prieš keisdami kitą pasiūlymą.

Įrašykite parinkiklius, 1 ir 2 fazių pasiūlymus ir šaltinio adresą į bilietą. Šios keturios reikšmės paaiškina daugumą site-to-site gedimų be skambučio.

Susiję straipsniai