Hvað felst í IPsec-tillögu? IKE- og ESP-reitir

IKE byrjar, báðir jafningjar auglýsa AES, og göngin mistakast samt með NO_PROPOSAL_CHOSEN. Annállinn nefnir tillöguna en ekki reitinn sem passaði ekki. Tillaga er eitt heildarboð, og einn ósamhæfur reitur ógildir alla samsetninguna en ekki bara þá línu. Að lesa hana sem poka af sjálfstæðum reikniritavalkostum er venjulega ástæðan fyrir því að ósamræmið verður ósýnilegt.

Tvær samningaviðræður með aðskildum tillagalistum

IKEv2 byggir tvö öryggissamtök. Fyrra er IKE SA, sem verndar sjálf stjórnskiptin, og seinna er CHILD SA, sem ber umferðina þína í gegnum ESP. Hvort um sig hefur sinn tillagalistann, og jafningi getur samþykkt annan og hafnað hinum.

Þessi skipting útskýrir algenga rugling: virkt IKE SA sannar aðeins að reiknirit stjórnrásarinnar hafi passað. Ef CHILD-tillagan mistakast ber göngin ekki einu sinni eitt pakka, þótt fyrsta stigið sé lokið og annálarnir líti heilbrigðir út efst.

Röðin innan hvers lista skiptir líka máli. Svarandinn velur úr röðuðum boðum frumkvæðisaðilans, svo að færa víðtækt samhæfa færslu yfir þrönga breytir því hvaða sett er sett upp án þess að nokkurt reikniritnafn breytist. Festu þessa röð í stillingunni í stað þess að treysta á sjálfgefin gildi. Stöðug röð gerir samanburð annála milli staða einnig merkingarbæran.

Hvaða reitir tilheyra hvaða tillögu

Reitasettið er lítið, en það er ekki eins í báðum viðræðum. Lestu töfluna línu fyrir línu, því reitur í einum dálki getur vantað í hinum. Setningafræðin er mismunandi eftir útfærslum; tillagaskjöl strongSwan eru ein áþreifanleg heimild.

Dulkóðunareiturinn nefnir dulritið og í flestum setningafræðum lengd lykilsins. Heilleikareiturinn nefnir tætuna sem notuð er til að sannreyna dulritaðan texta, og PRF nefnir fallið sem leiðir lykilefni fyrir IKE SA. DH-hópurinn kemur á fersku sameiginlegu leyndarefni, og þess vegna birtist hann á báðum hliðum en í mismunandi tilgangi.

Lengri raðnúmer tilheyra aðeins gagnaleiðinni. Þau víkka raðrúmið og eru samin sem hluti af CHILD-tillögunni, svo ósamræmi þar hafnar CHILD-boði á meðan IKE SA helst ósnortið.

Hvernig eitt heildarboð er valið

Hver tillaga er sett, og svarandinn leitar að setti þar sem hver skilyrtur reitur er ásættanlegur. Tveir listar geta báðir innihaldið AES og SHA-256 og samt ekki haft neina samhæfa færslu, því lengd lykils, PRF eða DH-hópur er mismunandi. Samanburðurinn fer fram fyrir hverja tillögu, ekki fyrir hvert reiknirit.

Þegar ekkert passar sendir svarandinn NO_PROPOSAL_CHOSEN með þeirri SA-tegund sem mistókst. Lestu hvaða tillagalist tilkynningin vísar til áður en þú breytir stillingunni; að skipta um ESP-reiknirit þegar IKE-tillögunni var hafnað eyðir einni kembiflotu.

Valkvæmt er að þekkja valhegðunina þegar þú stillir snið. Sumar útfærslur kjósa röð frumkvæðisaðilans, aðrar raða upp á ný eftir staðbundinni stefnu, svo sett sem virkar milli tveggja söluaðila getur hverfið þegar þú veltir því hvaða hlið hefur sambandið.

AEAD fjarlægir reit í stað þess að bæta við einum

AES-GCM og ChaCha20-Poly1305 sannreyna og dulkóða í einni aðgerð. Þegar annað hvort er valið fyrir ESP er heilleikareikniritið ekki samið sérstaklega, því AEAD-gerðin nær þegar yfir það. Þess vegna er tillaga sem parar AES-GCM við SHA-256 í besta falli óþörf og í versta falli hafnað.

PRF er enn aðskilið á IKE-hliðinni, þar sem það leiðir lykla fyrir stjórnrásina í stað þess að vernda farminn. Þess vegna getur IKE-tillaga löglega sameinað AEAD-dulrit með PRF og DH-hópi, á meðan samsvarandi ESP-tillaga telur aðeins upp AEAD-dulritið og valfrjálsa PFS-hópinn.

Lykillengd er hluti dulritunarmerkisins, svo AES-128-GCM og AES-256-GCM eru mismunandi boð. Snið afritað úr leiðarvísi sem gerði ráð fyrir 256-bit lyklum passar ekki við endapunkt sem er stilltur fyrir 128-bit, jafnvel þótt báðar línur segi AES-GCM. Tveir jafningjar geta komið sér saman um dulritunarfjölskylduna og hafnað hvort öðru samt vegna tölunnar á eftir bandstriknu.

Lestu uppsetta SA, ekki stillinguna

Stillingin með tillagalistanum er boð; uppsetta SA er niðurstaðan. Á strongSwan og Linux-kjarna eru báðar sýnirnar í boði:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas prentar samningsreikniritin fyrir hverja SA, að því meðtöldu hvort CHILD notar AEAD. ip xfrm state sýnir hvað kjarninn setti í raun upp, og þar er staðurinn til að staðfesta að endurnýjun lykla hafi ekki dottið aftur í annað sett en það sem þú skjalfestir.

Geymdu þessa úttak við stillinguna eftir lagfæringu. Þegar uppfærsla biðlarans breytir sjálfgildum hans gefur skráða settið þér grunnlínu til samanburðar, og samanburðurinn bendir á reitinn sem færðist í stað þess að hefja rannsóknina frá byrjun.