Od strongSwan k AWS Site-to-Site: prečo Child SA nič nevyberá

IKE tunel môže byť aktívny, zatiaľ čo podradená asociácia vylučuje vaše podsiete. Najprv porovnajte miestny a vzdialený CIDR v AWS s leftsubnet a rightsubnet.

Konzola hlási up, strongSwan vykazuje nadviazanú IKE asociáciu a pakety napriek tomu neprichádzajú. Ďalšia vec, ktorú treba porovnať, nie je predzdieľaný kľúč, ale dvojica prefixov, o ktorých si každá strana myslí, že ich tunel chráni. Prejdite kontroly nižšie v poradí, pretože prvé dve rozhodujú, či tunel vôbec môže prenášať vašu prevádzku.

Preložte názvy z AWS do terminológie strongSwanu

AWS opisuje spojenie zo strany zákazníka: adresa zákazníckej brány a miestny CIDR patria vám a vzdialený CIDR patrí VPC. strongSwan nazýva oba konce left a right, váš prefix je v leftsubnet a prefix VPC v rightsubnet. Prehodenie jednej dvojice vytvorí tunel, ktorý vyjednáva a vyberá nesprávnu prevádzku.

Stiahnite konfiguráciu, ktorú AWS pre spojenie vygeneruje, a berte ju ako referenciu práve pre toto spojenie, vrátane adries tunela a prefixov. Ak pri vytváraní necháte obe polia CIDR prázdne, služba použije predvolenú hodnotu 0.0.0.0/0 na každej strane. Router nakonfigurovaný s úzkym prefixom sa s ňou potom nikdy nezhodne, takže polia buď vyplňte, alebo selektor vedome rozšírte.

Nezhoda tu vyzerá ako zlyhanie smerovania, ale nie je ňou.

Zafixujte adresu, ktorú AWS skutočne vidí

Router za NAT môže vysielať IKE z rozhrania, o ktorom sa protistrana nikdy nedozvedela. Adresa brány zaznamenaná v AWS musí byť tá, ktorú AWS vidí na sieti, a router musí byť pripútaný k tej istej miestnej adrese namiesto toho, aby sa riadil predvolenou trasou.

conn %default
    local_addrs = 203.0.113.10

V strongSwane vyberá local_addrs zdrojovú adresu pre IKE a staršie konfigurácie OpenSwan zapisujú rovnakú myšlienku ako left. Nasmerujte ju na rozhranie s verejnou adresou, potom na samotnom zariadení NAT overte, že UDP 500 a 4500 dosiahnu tohto hostiteľa, pretože pravidlo zostávajúce po predchádzajúcom routeri ich ticho zahadzuje. Správna dvojica selektorov s nesprávnou zdrojovou adresou stále zlyháva a log obviní návrh. Práve preto si zdrojová adresa zaslúži vlastnú kontrolu.

Potvrďte pravidlo preposielania, namiesto toho, aby ste ho predpokladali, pretože pravidlo, ktoré bolo správne pre predchádzajúci router, často zostáva.

Riešte fázu 1 a fázu 2 oddelene

AWS zobrazuje možnosti IKE a ESP ako samostatné zoznamy. Sada IKE, ktorú prijmú obe strany, nič nehovorí o návrhu ESP, pretože oba zoznamy sú nezávislé. Prečítajte oba z vygenerovanej konfigurácie a porovnajte ich jeden po druhom.

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

Syntax sa medzi implementáciami neprenáša. Dvojica, ktorá funguje v OpenSwane, napríklad phase2alg=aes_gcm s ike=aes256-sha1;modp1024, potrebuje preklad do tvaru esp= a ike= strongSwanu a názvy algoritmov sa líšia. Keďže GCM overuje pravosť počas šifrovania, nepotrebuje samostatnú transformáciu integrity, na rozdiel od sady CBC spárovanej so SHA. Riadok fázy 2 vložený z jedného démona do druhého bez prekladu vyvolá odmietnutie, ktoré sa číta ako nezhoda selektorov.

Kontrolujte podradenú asociáciu, nie indikátor tunela

Ak sa spojenie načíta, ale podradená asociácia nevznikne, bolo odmietnuté buď navrhnutie, alebo selektory. Ak podradená asociácia vznikne a jej selektory vylučujú vaše prefixy, pakety sa filtrujú skôr, než sa dostanú do tunela. Indikátor konzoly pokrýva iba úroveň IKE, takže nedokáže povedať, ktorá z tých dvoch vecí nastala.

ipsec statusall

Nájdite podradenú bezpečnostnú asociáciu a prečítajte selektory prevádzky vytlačené vedľa nej, potom ich porovnajte s prefixami z vygenerovanej konfigurácie.

Testujte z hostiteľa v miestnom prefixe na hostiteľa v prefixe VPC a skontrolujte spiatočnú cestu aj prípadnú bezpečnostnú skupinu alebo sieťový ACL na strane AWS. Správne selektory neochránia paket pred neskorším zahodením.

Keď to po zhode selektorov stále nefunguje

Potvrďte, že trasa na oboch stranách vedie k tunelu, a potom potvrďte, že zariadenie NAT neprepisuje prevádzku spôsobom, ktorý politika neočakáva. Tunel založený na politike porovnáva adresy paketov, takže preklad použitý po rozhodnutí politiky mení výsledok.

Zaznamenajte jeden paket na vstupe a jeden na výstupe na každej strane, než zmeníte ďalší návrh.

Zapíšte selektory, návrhy fázy 1 a fázy 2 a zdrojovú adresu do tiketu. Tieto štyri hodnoty vysvetľujú väčšinu zlyhaní site-to-site bez volania.

Súvisiace články