Zer sartzen da IPsec proposamen batean? IKE eta ESP eremuak

IKE hasten da, bi aldeek AES iragartzen dute, eta tunelek huts egiten du oraindik NO_PROPOSAL_CHOSEN-ekin. Erregistroak proposamena izendatzen du, baina ez bat ez zetorren eremua. Proposamen bat eskaintza oso bat da, eta eremu bateraezin batek konbinazio osoa baliogabetzen du, ez lerro hori soilik. Algoritmo-hautakera independenteen zaku gisa irakurtzea da desadostasuna ikusezin mantentzen duen ohiko arrazoia.

Bi negoziazio proposamen-zerrenda bereiziekin

IKEv2-k bi segurtasun-elkarte eraikitzen ditu. Lehenengoa IKE SA da, kontrol-trukea bera babesten duena, eta bigarrena CHILD SA da, zure trafikoa ESP bidez eramaten duena. Bakoitzak bere proposamen-zerrenda du, eta pare batek bat onar dezake eta bestea baztertu.

Banaketa horrek nahasmen ohiko bat azaltzen du: funtzionatzen duen IKE SA batek kontrol-kanaleko algoritmoak bat etorri zirela bakarrik frogatzen du. CHILD proposamenak huts egiten badu, tunelek ez du pakete bakarra eramaten, lehen fasea osatuta egon arren eta erregistroak goialdean osasuntsu egon arren.

Zerrenda bakoitzaren barruko ordena ere garrantzitsua da. Erantzuleak hasieratzailearen eskaintza ordenatuen artean aukeratzen du, beraz, eremu zabal bat oso bateragarri den sarrera estu baten gainera mugitzeak zein multzo instalatuko den aldatzen du, algoritmo-izen bakarra ere aldatu gabe. Finkatu ordena hori konfigurazioan, balio lehenetsietan fidatu beharrean. Ordena egonkorrak guneen arteko erregistroen alderaketa esanguratsu egiten du.

Zein eremu dagokio zein proposameneri

Eremu-multzoa txikia da, baina ez da berbera bi negoziazioetan. Irakurri taula errenkadaz errenkada, zutabe bateko eremu bat bestean falta baitaiteke. Sintaxia inplementazioaren arabera aldatzen da; strongSwan-en proposamen-dokumentazioa erreferentzia zehatz bat da.

Zifratze-eremuek zifratzailea eta, sintaxi gehienetan, haren gako-luzera adierazten dituzte. Osotasun-eremuak testu zifratua autentifikatzeko erabiltzen den hash-a aipatzen du, eta PRF-k IKE SA-rako gako-materiala eratortzen duen funtzioa aipatzen du. DH taldeak elkar partekatutako material sekretu berria ezartzen du, eta horregatik agertzen da bi aldeetan, baina helburu desberdinetarako.

Luzatutako sekuentzia-zenbakiak datu-bideari soilik dagozkio. Sekuentzia-espazioa zabaltzen dute eta CHILD proposamenaren parte gisa negoziatzen dira, beraz, han dagoen desadostasun batek CHILD eskaintza baztertzen du, IKE SA ukitu gabe uzten duen bitartean.

Nola hautatzen den eskaintza oso bat

Proposamen bakoitza multzo bat da, eta erantzuleak derrigorrezko eremu bakoitza onargarria den multzo baten bila dabil. Bi zerrendek AES eta SHA-256 eduki ditzakete eta hala ere sarrera bateragarririk ez izan, gako-luzera, PRF edo DH taldea desberdinak baitira. Alderaketa proposamen bakoitzeko egiten da, ez algoritmo bakoitzeko.

Ezerk bat egiten ez duenean, erantzuleak NO_PROPOSAL_CHOSEN bidaltzen du huts egin duen SA motarekin. Irakurri jakinarazpena zein proposamen-zerrendari dagokion konfigurazioa editatu aurretik; IKE proposamena baztertu denean ESP algoritmoak aldatzeak arazketa-ziklo bat galtzen du.

Hautaketa-portaera ezagutzea merezi du profil bat doitzekoan. Inplementazio batzuek hasieratzailearen ordena nahiago dute, besteek tokiko politikaren arabera berrordenatzen dute, beraz bi hornitzaileren artean funtzionatzen duen multzo bat desagertu daiteke konexioa zein aldek hasten duen alderantzikatzen duzunean.

AEAD-k eremu bat kentzen du, ez gehitzen

AES-GCM eta ChaCha20-Poly1305 eragiketa bakarrean autentifikatzen eta zifratzen dute. Horietako bat ESPrako hautatzen denean, osotasun-algoritmoa ez da bereiz negoziatzen, AEAD eraikuntzak jada estaltzen baitu. Beraz, AES-GCM SHA-256-rekin lotzen duen proposamena soberan dago kasurik onenean eta baztertua kasurik txarrenean.

PRF bereizita jarraitzen du IKE aldean, kontrol-kanalerako gakoak eratortzen baititu, karga erabilgarriak babestu ordez. Horregatik IKE proposamen batek AEAD zifratzailea legez konbina dezake PRF batekin eta DH talde batekin, dagokion ESP proposamenak AEAD zifratzailea eta aukerako PFS taldea soilik zerrendatzen dituen bitartean.

Gako-luzera zifratze-tokenaren parte da, beraz AES-128-GCM eta AES-256-GCM eskaintza desberdinak dira. 256-bit gakoak suposatzen zituen gida batetik kopiatutako profil bat ez da bat etorriko 128-bit-erako konfiguratuta dagoen muturrekin, bi lerroek AES-GCM esan arren. Bi parek zifratzaile-familia adostu dezakete eta hala ere elkar baztertu marratxo ondoko zenbakiagatik.

Irakurri instalatutako SA, ez konfigurazioa

Konfiguratutako proposamen-zerrenda eskaintza bat da; instalatutako SA emaitza da. strongSwan-en eta Linux nukleoan, bi ikuspegiak eskura daude:

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

swanctl --list-sas SA bakoitzeko negoziatutako algoritmoak inprimatzen ditu, CHILD-ek AEAD erabiltzen duen ala ez barne. ip xfrm state nukleoak benetan zer instalatu zuen erakusten du, eta hori da gako-berritze batek dokumentatu zenuenaren desberdina den multzo batera atzera egin ez zuen egiaztatzeko lekua.

Gorde irteera hori konfigurazioaren ondoan konponketa baten ondoren. Bezeroaren eguneraketa batek bere balio lehenetsiak aldatzen dituenean, erregistratutako multzoak alderatzeko oinarri bat ematen dizu, eta alderaketak mugitu den eremua seinalatzen du, ikerketa hasieratik berriro hasi ordez.