strongSwanist AWS Site-to-Site’i: miks Child SA midagi ei vali

IKE-tunnel võib olla üleval, samal ajal kui alamassotsiatsioon välistab sinu alamsuvõrgud. Kõigepealt võrdle AWS-i kohalikku ja kaugemat CIDR-i parameetritega leftsubnet ja rightsubnet.

Konsool näitab olekut up, strongSwan teatab loodud IKE-assotsiatsioonist ja paketid ikkagi ei saabu. Järgmine asi, mida võrrelda, ei ole eeljagatud võti, vaid prefiksite paar, mille kohta kumbki pool arvab, et tunnel neid kaitseb. Käi allolevad kontrollid järjekorras läbi, sest kaks esimest otsustavad, kas tunnel suudab sinu liiklust üldse kanda.

Tõlgi AWS-i nimetused strongSwani terminiteks

AWS kirjeldab ühendust kliendi poolelt: kliendi lüüsi aadress ja kohalik CIDR kuuluvad sulle ning kaugem CIDR kuulub VPC-le. strongSwan nimetab kaks otsa left ja right, sinu prefiks on leftsubnetis ja VPC prefiks rightsubnetis. Ühe paari ümberpööramine loob tunneli, mis läbiräägib ja valib vale liikluse.

Laadi alla konfiguratsioon, mille AWS ühenduse jaoks genereerib, ja käsitle seda just selle ühenduse võrdlusalusena, sealhulgas tunneli aadressid ja prefiksid. Kui jätad loomisel mõlemad CIDR-väljad tühjaks, kasutab teenus mõlemal poolel vaikeväärtust 0.0.0.0/0. Kitsa prefiksiga seadistatud ruuter ei sobi sellega siis kunagi kokku, seega kas täida väljad või laienda valijat teadlikult.

Erinevus siin näeb välja nagu marsruutimise rike ja ei ole seda.

Kinnita aadress, mida AWS tegelikult näeb

NAT-i taga olev ruuter võib saata IKE-d liidesest, millest vastaspool pole kunagi teadlikuks saanud. AWS-i kirja pandud lüüsi aadress peab olema see, mida AWS võrgus näeb, ja ruuter tuleb kinnitada samale kohalikule aadressile, selle asemel et järgida oma vaikemarsruuti.

conn %default
    local_addrs = 203.0.113.10

strongSwanis valib local_addrs IKE jaoks lähteaadressi ja vanemad OpenSwani konfiguratsioonid kirjutavad sama mõtte kujul left. Suuna see liidesele, millel on avalik aadress, seejärel kontrolli NAT-seadmes endas, et UDP 500 ja 4500 jõuavad sellesse hosti, sest varasemast ruuterist jäänud reegel viskab need vaikselt kõrvale. Õige valijapaar vale lähteaadressiga siiski ebaõnnestub ja logi süüdistab ettepanekut. Just see eksitamine on põhjus, miks lähteaadress väärib eraldi kontrolli.

Kinnita edastusreegel, selle asemel et seda eeldada, sest eelmise ruuteri jaoks õige reegel jääb sageli alles.

Käsitle faasi 1 ja faasi 2 eraldi

AWS esitab IKE ja ESP valikud eraldi loenditena. IKE komplekt, mille mõlemad pooled heaks kiidavad, ei ütle ESP ettepaneku kohta midagi, sest need kaks loendit on sõltumatud. Loe mõlemad genereeritud konfiguratsioonist ja võrdle neid ükshaaval.

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

Süntaks ei liigu rakenduste vahel. Paar, mis töötab OpenSwanis, näiteks phase2alg=aes_gcm koos ike=aes256-sha1;modp1024, vajab tõlkimist strongSwani kujule esp= ja ike=, ja algoritmide nimed erinevad. Kuna GCM autendib krüpteerimise ajal, ei vaja see eraldi terviklikkuse teisendust, erinevalt SHA-ga paaris olevast CBC komplektist. Ühest deemonist teise ilma tõlketa kleepitud faasi 2 rida tekitab tagasilükkamise, mis kõlab nagu valija mittevastavus.

Kontrolli alamassotsiatsiooni, mitte tunneli indikaatorit

Kui ühendus laaditakse, aga ükski alamassotsiatsioon ei tõuse, lükati tagasi kas ettepanek või valijad. Kui alamassotsiatsioon tõuseb ja selle valijad välistavad sinu prefiksid, filtreeritakse paketid enne tunnelini jõudmist. Konsooli indikaator katab ainult IKE-tasandi, seega ei saa see öelda, kumb kahest juhtus.

ipsec statusall

Otsi üles lapse turvaassotsiatsioon ja loe selle kõrvale trükitud liiklusvalijad, seejärel võrdle neid genereeritud konfiguratsiooni prefiksitega.

Testi hostist kohaliku prefiksi sees hostini VPC prefiksi sees ning kontrolli tagasiteed ja kõiki AWS-i poolseid turvagruppe või võrgu-ACL-e. Õiged valijad ei kaitse paketti hilisema kõrvaleviskamise eest.

Kui see pärast valijate sobimist ikka ei õnnestu

Kinnita, et marsruut mõlemal poolel osutab tunnelile, seejärel kinnita, et NAT-seade ei kirjuta liiklust ümber viisil, mida poliitika ei eelda. Poliitikapõhine tunnel sobitab paketi aadresse, seega pärast poliitikaotsust rakendatav tõlge muudab tulemust.

Logi üks sissetulev ja üks väljuv pakett kummalgi poolel enne, kui muudet teist ettepanekut.

Kirjuta valijad, faasi 1 ja faasi 2 ettepanekud ning lähteaadress piletisse. Need neli väärtust selgitavad enamikku site-to-site-tõrkeid ilma kõneta.

Seotud artiklid