strongSwan al AWS Site-to-Site: kial la Child SA elektas nenion

IKE-tunelo povas esti aktiva dum la infana asociiĝo ekskludas viajn subretojn. Unue komparu la lokan kaj malproksiman CIDR en AWS kun leftsubnet kaj rightsubnet.

La konzolo montras staton up, strongSwan raportas establitajn IKE-asociojn, kaj la pakaĵoj ankoraŭ ne alvenas. La sekva afero komparota estas ne la antaŭe dividita ŝlosilo, sed la paro da prefiksoj, kiujn ĉiu flanko kredas protektataj de la tunelo. Trapasu la subajn kontrolojn laŭorde, ĉar la du unuaj decidas, ĉu la tunelo entute povas porti vian trafikon.

Traduku la nomojn de AWS al la terminoj de strongSwan

AWS priskribas la konekton el la klienta flanko: la adreso de la klienta pordego kaj la loka CIDR apartenas al vi, kaj la malproksima CIDR apartenas al la VPC. strongSwan nomas la du finojn left kaj right, kun via prefikso en leftsubnet kaj la VPC-prefikso en rightsubnet. Inversigi unu paron produktas tunelon, kiu intertraktas kaj elektas la malĝustan trafikon.

Elŝutu la agordon, kiun AWS generas por la konekto, kaj traktu ĝin kiel referencon por ĝuste tiu konekto, inkluzive de tunelaj adresoj kaj prefiksoj. Se vi lasos ambaŭ CIDR-kampojn malplenaj ĉe kreado, la servo uzos la defaŭlton 0.0.0.0/0 ĉe ĉiu flanko. Enkursigilo agordita kun mallarĝa prefikso tiam neniam kongruos kun ĝi, do aŭ plenigu la kampojn aŭ intence plilarĝigu la elektilon.

Miskongruo ĉi tie aspektas kiel enkursiga fiasko kaj ne estas tia.

Fiksu la adreson, kiun AWS efektive vidas

Enkursigilo malantaŭ NAT povas fonti IKE el interfaco, pri kiu la kontraŭa flanko neniam sciis. La enirporda adreso registrita en AWS devas esti tiu, kiun AWS vidas en la reto, kaj la enkursigilo devas esti fiksita al la sama loka adreso anstataŭ sekvi sian defaŭltan itineron.

conn %default
    local_addrs = 203.0.113.10

En strongSwan local_addrs elektas la fontan adreson por IKE, kaj pli malnovaj OpenSwan-agordoj skribas la saman ideon kiel left. Direktu ĝin al la interfaco, kiu havas la publikan adreson, poste kontrolu en la NAT-aparato mem, ke UDP 500 kaj 4500 atingas tiun gastiganton, ĉar regulo restinta de antaŭa enkursigilo silento forĵetas ilin. Ĝusta elektila paro kun malĝusta fonta adreso ankoraŭ malsukcesas, kaj la protokolo kulpigos la proponon. Tiu misgvidado estas kial la fonta adreso meritas propran kontrolon.

Konfirmu la plusendan regulon anstataŭ supozi ĝin, ĉar regulo, kiu estis ĝusta por la antaŭa enkursigilo, ofte restas.

Traktu fazon 1 kaj fazon 2 aparte

AWS montras IKE- kaj ESP-opciojn kiel apartaj listoj. IKE-aro, kiun ambaŭ flankoj akceptas, diras nenion pri la ESP-propono, ĉar la du listoj estas sendependaj. Legu ambaŭ el la generita agordo kaj komparu ilin unu post la alia.

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

Sintakso ne vojaĝas inter realigoj. Paro, kiu funkcias en OpenSwan, ekzemple phase2alg=aes_gcm kun ike=aes256-sha1;modp1024, bezonas tradukon al la formo esp= kaj ike= de strongSwan, kaj la algoritmaj nomoj diferencas. Ĉar GCM aŭtentikigas dum ĝi ĉifras, ĝi bezonas neniun apartan integrecan transformon, malkiel CBC-aro parigita kun SHA. Linio de fazo 2 algluita de unu demono en alian sen traduko kaŭzas malakcepton, kiu legiĝas kiel miskongruo de elektiloj.

Kontrolu la infanan asociiĝon, ne la tunelan indikilon

Se la konekto ŝargiĝas sed neniu infana asociiĝo aperas, aŭ la propono aŭ la elektiloj estis malakceptitaj. Se infano aperas kaj ĝiaj elektiloj ekskludas viajn prefiksojn, pakaĵoj filtriĝas antaŭ ol ili atingas la tunelon. La indikilo de la konzolo kovras nur la IKE-nivelon, do ĝi ne povas diri al vi, kiu el la du okazis.

ipsec statusall

Serĉu la infanan sekurecan asociiĝon kaj legu la trafikajn elektilojn presitajn apud ĝi, poste komparu ilin kun la prefiksoj el la generita agordo.

Testu de gastiganto en la loka prefikso al gastiganto en la VPC-prefikso, kaj kontrolu la revenan itineron plus ajnan sekurecan grupon aŭ retan ACL ĉe la AWS-flanko. Ĝustaj elektiloj ne protektas pakaĵon kontraŭ posta forĵeto.

Kiam ĝi ankoraŭ malsukcesas post kiam la elektiloj kongruas

Konfirmu, ke la itinero ambaŭflanke direktiĝas al la tunelo, poste konfirmu, ke la NAT-aparato ne reskribas trafikon tiel, kiel la politiko ne atendas. Politiko-bazita tunelo kongruas pakaĵajn adresojn, do traduko aplikata post la politika decido ŝanĝas la rezulton.

Registru unu enirantan kaj unu elirantan pakaĵon ĉe ĉiu flanko antaŭ ol ŝanĝi alian proponon.

Notu la elektilojn, la proponojn de fazo 1 kaj fazo 2 kaj la fontan adreson en la bileto. Tiuj kvar valoroj klarigas la plej multajn site-to-site-fiaskojn sen voko.

Rilataj artikoloj