strongSwan k AWS Site-to-Site: proč Child SA nic nevybírá

IKE tunel může být aktivní, zatímco podřízená asociace vylučuje vaše podsítě. Nejprve porovnejte místní a vzdálený CIDR v AWS s leftsubnet a rightsubnet.

Konzole hlásí stav up, strongSwan vykazuje navázanou IKE asociaci, a pakety přesto nedorazí. Další věc, kterou je třeba porovnat, není předsdílený klíč, ale dvojice prefixů, o nichž si každá strana myslí, že je tunel chrání. Projděte kontroly níže v pořadí, protože první dvě rozhodují, zda tunel vůbec může přenášet váš provoz.

Přeložte názvy z AWS do terminologie strongSwanu

AWS popisuje spojení ze strany zákazníka: adresa zákaznické brány a místní CIDR patří vám a vzdálený CIDR patří VPC. strongSwan nazývá oba konce left a right, váš prefix je v leftsubnet a prefix VPC v rightsubnet. Při prohození jedné dvojice vznikne tunel, který vyjednává a vybírá nesprávný provoz.

Stáhněte konfiguraci, kterou AWS pro spojení vygeneruje, a berte ji jako referenci právě pro toto spojení, včetně adres tunelu a prefixů. Pokud při vytváření necháte obě pole CIDR prázdná, služba použije výchozí hodnotu 0.0.0.0/0 na každé straně. Router nakonfigurovaný s úzkým prefixem se s ní pak nikdy neshodne, takže pole buď vyplňte, nebo selektor vědomě rozšiřte.

Neshoda zde vypadá jako selhání směrování, ale není jím.

Zafixujte adresu, kterou AWS skutečně vidí

Router za NAT může vysílat IKE z rozhraní, o kterém se protější strana nikdy nedozvěděla. Adresa brány zaznamenaná v AWS musí být ta, kterou AWS vidí na síti, a router musí být připoután ke stejné místní adrese, místo aby se řídil výchozí trasou.

conn %default
    local_addrs = 203.0.113.10

V strongSwanu vybírá local_addrs zdrojovou adresu pro IKE a starší konfigurace OpenSwan zapisují stejnou myšlenku jako left. Nasměrujte ji na rozhraní s veřejnou adresou, poté na samotném zařízení NAT ověřte, že UDP 500 a 4500 dosáhnou tohoto hostitele, protože pravidlo zbylé po předchozím routeru je tiše zahazuje. Správná dvojice selektorů s nesprávnou zdrojovou adresou stále selhává a log obviní návrh. Právě proto si zdrojová adresa zaslouží vlastní kontrolu.

Potvrďte pravidlo přesměrování, místo abyste je předpokládali, protože pravidlo, které bylo správné pro předchozí router, často zůstává.

Řešte fázi 1 a fázi 2 odděleně

AWS zobrazuje volby IKE a ESP jako samostatné seznamy. Sada IKE, kterou obě strany přijmou, nic neříká o návrhu ESP, protože oba seznamy jsou nezávislé. Přečtěte oba z vygenerované konfigurace a porovnejte je jeden po druhém.

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

Syntaxe se mezi implementacemi nepřenáší. Dvojice, která funguje v OpenSwanu, například phase2alg=aes_gcm s ike=aes256-sha1;modp1024, potřebuje překlad do tvaru esp= a ike= strongSwanu a názvy algoritmů se liší. Protože GCM ověřuje pravost při šifrování, nepotřebuje samostatnou transformaci integrity, na rozdíl od sady CBC spárované se SHA. Řádek fáze 2 vložený z jednoho démona do druhého bez překladu vyvolá odmítnutí, které vypadá jako neshoda selektorů.

Kontrolujte podřízenou asociaci, ne indikátor tunelu

Pokud se spojení načte, ale podřízená asociace nevznikne, bylo odmítnuto buď navržení, nebo selektory. Pokud podřízená asociace vznikne a její selektory vylučují vaše prefixy, pakety se filtrují dříve, než se dostanou do tunelu. Indikátor konzole pokrývá pouze úroveň IKE, takže nedokáže říci, která z těchto dvou věcí nastala.

ipsec statusall

Najděte podřízenou bezpečnostní asociaci a přečtěte selektory provozu vytištěné vedle ní, poté je porovnejte s prefixy z vygenerované konfigurace.

Testujte z hostitele v místním prefixu na hostitele v prefixu VPC a zkontrolujte zpětnou cestu i případnou bezpečnostní skupinu nebo síťový ACL na straně AWS. Správné selektory neochrání paket před pozdějším zahozením.

Když to po shodě selektorů stále nefunguje

Potvrďte, že trasa na obou stranách vede k tunelu, a poté potvrďte, že zařízení NAT nepřepisuje provoz způsobem, který politika neočekává. Tunel založený na politice porovnává adresy paketů, takže překlad použitý po rozhodnutí politiky mění výsledek.

Zaznamenejte jeden paket na vstupu a jeden na výstupu na každé straně, než změníte další návrh.

Zapište selektory, návrhy fáze 1 a fáze 2 a zdrojovou adresu do tiketu. Tyto čtyři hodnoty vysvětlují většinu selhání site-to-site bez volání.

Související články