Mula strongSwan hanggang AWS Site-to-Site: bakit walang pinipili ang Child SA

Maaaring aktibo ang IKE tunnel habang ibinubukod ng child association ang iyong mga subnet. Ihambing muna ang lokal at malayong CIDR ng AWS sa leftsubnet at rightsubnet.

Nagpapakita ng up ang console, nag-uulat ang strongSwan ng naitatag na IKE association, at hindi pa rin dumarating ang mga packet. Ang susunod na ihahambing ay hindi ang pre-shared key kundi ang pares ng prefix na inaakala ng bawat panig na pinoprotektahan ng tunnel. Sundin ang mga pagsusuri sa ibaba nang ayon sa pagkakasunod-sunod, dahil ang unang dalawa ang nagpapasya kung kayang dalhin ng tunnel ang iyong trapiko.

Isalin ang mga pangalan ng AWS sa mga termino ng strongSwan

Inilalarawan ng AWS ang koneksyon mula sa panig ng customer: pag-aari mo ang address ng customer gateway at ang lokal na CIDR, at ang malayong CIDR ay pag-aari ng VPC. Tinatawag ng strongSwan ang dalawang dulo na left at right, nasa leftsubnet ang iyong prefix at nasa rightsubnet ang prefix ng VPC. Kapag binaligtad ang isang pares, nakakakuha ka ng tunnel na nakikipagnegosasyon at pumipili ng maling trapiko.

I-download ang configuration na ginagawa ng AWS para sa koneksyon at ituring itong sanggunian para sa mismong koneksyong iyon, kasama ang mga address at prefix ng tunnel. Kung iiwan mong blangko ang dalawang CIDR field sa paggawa, gagamitin ng serbisyo ang default na 0.0.0.0/0 sa bawat panig. Ang router na naka-configure na may makitid na prefix ay hindi kailanman magtutugma, kaya punan ang mga field o sadyang palawakin ang selector.

Ang pagkakaiba rito ay mukhang pagkabigo sa routing at hindi naman.

Ipinako ang address na talagang nakikita ng AWS

Ang router sa likod ng NAT ay maaaring magpadala ng IKE mula sa interface na hindi kailanman nalaman ng kabilang panig. Ang gateway address na naitala sa AWS ay dapat ang nakikita ng AWS sa network, at ang router ay dapat na ipinako sa parehong lokal na address sa halip na sundin ang default na ruta.

conn %default
    local_addrs = 203.0.113.10

Sa strongSwan, pinipili ng local_addrs ang source address para sa IKE, at isinusulat ng mas lumang OpenSwan configuration ang parehong ideya bilang left. Ituro ito sa interface na may pampublikong address, pagkatapos ay tiyakin sa mismong NAT device na naaabot ng UDP 500 at 4500 ang host na iyon, dahil ang panuntunang natira mula sa dating router ay tahimik na nagtatapon sa kanila. Nabibigo pa rin ang tamang pares ng selector na may maling source address, at sisisihin ng log ang panukala. Ang panlilinlang na iyon ang dahilan kung bakit ang source address ay karapat-dapat sa sariling pagsusuri.

Tiyakin ang forwarding rule sa halip na ipagpalagay ito, dahil ang panuntunang tama para sa dating router ay madalas na natitira.

Paghiwalayin ang paghawak sa yugto 1 at yugto 2

Ipinapakita ng AWS ang mga pagpipilian sa IKE at ESP bilang magkahiwalay na listahan. Ang IKE suite na tinatanggap ng dalawang panig ay walang sinasabi tungkol sa ESP proposal, dahil independiyente ang dalawang listahan. Basahin ang dalawa mula sa ginawang configuration at ihambing sila nang isa-isa.

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

Hindi naglalakbay ang syntax sa pagitan ng mga implementasyon. Ang pares na gumagana sa OpenSwan, halimbawa phase2alg=aes_gcm kasama ng ike=aes256-sha1;modp1024, ay kailangang isalin sa anyong esp= at ike= ng strongSwan, at magkaiba ang mga pangalan ng algorithm. Dahil nagpapatunay ang GCM habang nag-e-encrypt, hindi nito kailangan ang hiwalay na integrity transform, di gaya ng CBC suite na ipinares sa SHA. Ang linyang yugto 2 na idinikit mula sa isang daemon patungo sa isa nang walang salin ay gumagawa ng pagtanggi na binabasa na parang hindi pagtutugma ng selector.

Suriin ang child association, hindi ang tagapagpahiwatig ng tunnel

Kung nag-load ang koneksyon pero walang child association na umusbong, tinanggihan ang panukala o ang mga selector. Kung may child na umusbong at ibinubukod ng mga selector nito ang iyong mga prefix, sinasala ang mga packet bago pa makarating sa tunnel. Sinasaklaw lamang ng tagapagpahiwatig ng console ang antas ng IKE, kaya hindi nito masasabi kung alin sa dalawa ang nangyari.

ipsec statusall

Hanapin ang child security association at basahin ang mga traffic selector na nakalimbag sa tabi nito, pagkatapos ay ihambing ang mga ito sa mga prefix mula sa ginawang configuration.

Subukan mula sa host sa loob ng lokal na prefix patungo sa host sa loob ng prefix ng VPC, at suriin ang return path pati na ang anumang security group o network ACL sa panig ng AWS. Hindi pinoprotektahan ng tamang selector ang isang packet mula sa itatapon mamaya.

Kapag nabigo pa rin pagkatapos magtugma ang mga selector

Tiyakin na ang ruta sa dalawang panig ay tumuturo sa tunnel, pagkatapos ay tiyakin na hindi isinusulat muli ng NAT device ang trapiko sa paraang hindi inaasahan ng patakaran. Ang policy-based tunnel ay tumutugma sa mga address ng packet, kaya ang salin na inilapat pagkatapos ng pasya ng patakaran ay nagbabago ng resulta.

Mag-log ng isang papasok at isang palabas na packet sa bawat panig bago baguhin ang isa pang panukala.

Itala ang mga selector, ang mga panukala sa yugto 1 at yugto 2 at ang source address sa ticket. Ipinapaliwanag ng apat na halagang ito ang karamihan ng mga pagkabigo sa site-to-site nang walang tawag.

Kaugnay na mga artikulo