No strongSwan uz AWS Site-to-Site: kāpēc Child SA neizvēlas neko

IKE tunelis var būt aktīvs, kamēr atvasinātā asociācija izslēdz jūsu apakštīklus. Vispirms salīdziniet AWS lokālo un attālo CIDR ar leftsubnet un rightsubnet.

Konsole rāda up, strongSwan ziņo par izveidotu IKE asociāciju, un paketes tomēr neierodas. Nākamais, kas jāsalīdzina, nav iepriekš koplietotā atslēga, bet gan prefiksu pāris, kuru katra puse uzskata par tunela aizsargātu. Izpildiet tālāk minētās pārbaudes secīgi, jo pirmās divas izlemj, vai tunelis vispār spēj pārvadīt jūsu datplūsmu.

Pārtulkojiet AWS nosaukumus strongSwan terminos

AWS apraksta savienojumu no klienta puses: klienta vārtejas adrese un lokālais CIDR pieder jums, bet attālais CIDR pieder VPC. strongSwan abus galus sauc par left un right, jūsu prefikss ir leftsubnet, bet VPC prefikss — rightsubnet. Apgriežot vienu pāri, rodas tunelis, kas pārrunā un izvēlas nepareizo datplūsmu.

Lejupielādējiet konfigurāciju, ko AWS ģenerē savienojumam, un uzskatiet to par atsauci tieši šim savienojumam, ieskaitot tunela adreses un prefiksus. Ja izveides laikā abus CIDR laukus atstājat tukšus, pakalpojums katrā pusē izmanto noklusējumu 0.0.0.0/0. Maršrutētājs, kas konfigurēts ar šauru prefiksu, tad nekad nesakritīs, tāpēc vai nu aizpildiet laukus, vai apzināti paplašiniet atlasītāju.

Neatbilstība šeit izskatās pēc maršrutēšanas kļūdas, bet tā nav.

Nofiksējiet adresi, ko AWS faktiski redz

Maršrutētājs aiz NAT var sūtīt IKE no saskarnes, par kuru pretējā puse nekad nav uzzinājusi. AWS ierakstītajai vārtejas adresei jābūt tai, ko AWS redz tīklā, un maršrutētājs jāpiefiksē pie tās pašas lokālās adreses, nevis jāseko savam noklusējuma maršrutam.

conn %default
    local_addrs = 203.0.113.10

strongSwan gadījumā local_addrs izvēlas IKE avota adresi, un vecākas OpenSwan konfigurācijas to pašu ideju raksta kā left. Novirziet to uz saskarni, kurai ir publiskā adrese, pēc tam pašā NAT ierīcē pārbaudiet, vai UDP 500 un 4500 sasniedz šo resursdatoru, jo no iepriekšējā maršrutētāja palicis noteikums tos klusi izmet. Pareizs atlasītāju pāris ar nepareizu avota adresi tomēr neizdodas, un žurnāls vainos priekšlikumu. Tieši šī maldināšana ir iemesls, kāpēc avota adrese ir pelnījusi atsevišķu pārbaudi.

Apstipriniet pārsūtīšanas noteikumu, nevis pieņemiet to, jo noteikums, kas bija pareizs iepriekšējam maršrutētājam, bieži paliek.

1. un 2. fāzi aplūkojiet atsevišķi

AWS parāda IKE un ESP opcijas kā atsevišķus sarakstus. IKE komplekts, ko pieņem abas puses, neko neizsaka par ESP priekšlikumu, jo abi saraksti ir neatkarīgi. Izlasiet abus no ģenerētās konfigurācijas un salīdziniet tos pa vienam.

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

Sintakse nepārvietojas starp implementācijām. Pāris, kas darbojas OpenSwan, piemēram, phase2alg=aes_gcm ar ike=aes256-sha1;modp1024, ir jāpārtulko strongSwan formā esp= un ike=, un algoritmu nosaukumi atšķiras. Tā kā GCM autentificē šifrēšanas laikā, tam nav vajadzīga atsevišķa integritātes transformācija, atšķirībā no CBC komplekta, kas savienots pāri ar SHA. Rinda no 2. fāzes, kas bez tulkojuma ielīmēta no viena dēmona otrā, rada noraidījumu, kas lasās kā atlasītāju neatbilstība.

Pārbaudiet atvasināto asociāciju, nevis tuneļa indikatoru

Ja savienojums ielādējas, bet atvasinātā asociācija neparādās, ir noraidīts vai nu priekšlikums, vai atlasītāji. Ja atvasinātā parādās un tās atlasītāji izslēdz jūsu prefiksus, paketes tiek filtrētas pirms tunela sasniegšanas. Konsoles indikators aptver tikai IKE līmeni, tāpēc tas nevar pateikt, kurš no abiem notika.

ipsec statusall

Atrodiet atvasināto drošības asociāciju un izlasiet blakus uzdrukātos datplūsmas atlasītājus, pēc tam salīdziniet tos ar ģenerētās konfigurācijas prefiksiem.

Pārbaudiet no resursdatora lokālā prefiksa ietvaros uz resursdatoru VPC prefiksa ietvaros un pārbaudiet atgriešanās ceļu, kā arī jebkuru drošības grupu vai tīkla ACL AWS pusē. Pareizi atlasītāji nepasargā pakešu no vēlākas nomešanas.

Kad pēc atlasītāju sakrišanas joprojām neizdodas

Apstipriniet, ka maršruts abās pusēs ved uz tuneli, pēc tam apstipriniet, ka NAT ierīce nepārraksta datplūsmu tā, kā politika negaida. Uz politiku balstīts tunelis saskaņo pakešu adreses, tāpēc pēc politikas lēmuma piemērots tulkojums maina rezultātu.

Pirms maināt vēl vienu priekšlikumu, reģistrējiet vienu ienākošo un vienu izejošo paketi katrā pusē.

Ierakstiet atlasītājus, 1. un 2. fāzes priekšlikumus un avota adresi biļetenā. Šīs četras vērtības izskaidro lielāko daļu site-to-site kļūdu bez zvana.

Saistītie raksti