Kas ietilpst IPsec priekšlikumā? IKE un ESP lauki

IKE sākas, abas puses paziņo AES, un tunelis tomēr cieš neveiksmi ar NO_PROPOSAL_CHOSEN. Žurnāls nosauc priekšlikumu, bet ne lauku, kas nesaskanēja. Priekšlikums ir viens pilnīgs piedāvājums, un viens nesaderīgs lauks atceļ visu kombināciju, nevis tikai to rindu. Lasīt to kā maisu ar neatkarīgām algoritmu izvēlēm ir ierastais iemesls, kāpēc neatbilstība paliek neredzama.

Divas sarunas ar atsevišķiem priekšlikumu sarakstiem

IKEv2 veido divas drošības asociācijas. Pirmā ir IKE SA, kas aizsargā pašu vadības apmaiņu, un otrā ir CHILD SA, kas pārvadā jūsu datplūsmu caur ESP. Katrai ir savs priekšlikumu saraksts, un puse var pieņemt vienu un noraidīt otru.

Šis dalījums izskaidro bieži sastopamu apjukumu: strādājoša IKE SA pierāda tikai to, ka vadības kanāla algoritmi saskanēja. Ja CHILD priekšlikums cieš neveiksmi, tunelis nepārvadā nevienu paketi, lai gan pirmā fāze ir pabeigta un žurnāli augšpusē izskatās veseli.

Arī secība katrā sarakstā ir svarīga. Atbildētājs izvēlas no iniciatora sakārtotajiem piedāvājumiem, tāpēc plaši saderīga ieraksta pārvietošana virs šaura maina, kura kopa tiks instalēta, nemainot nevienu algoritma nosaukumu. Fiksējiet šo secību konfigurācijā, nevis paļaujieties uz noklusējuma vērtībām. Stabila secība arī padara žurnālu salīdzināšanu starp vietnēm jēgpilnu.

Kuri lauki pieder kuram priekšlikumam

Lauku kopa ir maza, bet abās sarunās tā nav identiska. Lasiet tabulu rindu pa rindai, jo vienas kolonnas lauks otrā var trūkt. Sintakse atšķiras atkarībā no ieviešanas; strongSwan priekšlikumu dokumentācija ir viens konkrēts atsauces avots.

Šifrēšanas lauks nosauc šifru un vairumā sintakšu arī tā atslēgas garumu. Integritātes lauks nosauc jaucējkodu, ko izmanto šifrētā teksta autentifikācijai, un PRF nosauc funkciju, kas atvasina atslēgas materiālu IKE SA vajadzībām. DH grupa izveido svaigu kopīgu slepenu materiālu, tāpēc tā parādās abās pusēs, bet ar atšķirīgiem mērķiem.

Paplašinātie secības numuri pieder tikai datu ceļam. Tie paplašina secības telpu un tiek sarunāti kā CHILD priekšlikuma daļa, tāpēc neatbilstība tur noraida CHILD piedāvājumu, kamēr IKE SA paliek neskarta.

Kā tiek izvēlēts viens pilnīgs piedāvājums

Katrs priekšlikums ir kopa, un atbildētājs meklē kopu, kurā katrs obligātais lauks ir pieņemams. Divi saraksti var abi saturēt AES un SHA-256 un tomēr nesaturēt nevienu saderīgu ierakstu, jo atšķiras atslēgas garums, PRF vai DH grupa. Salīdzināšana notiek pēc priekšlikuma, nevis pēc algoritma.

Kad nekas nesakrīt, atbildētājs sūta NO_PROPOSAL_CHOSEN ar neizdevušos SA tipu. Pirms konfigurācijas rediģēšanas izlasiet, uz kuru priekšlikumu sarakstu attiecas paziņojums; ESP algoritmu maiņa, kad IKE priekšlikums tika noraidīts, izšķērdē vienu atkļūdošanas ciklu.

Izvēles uzvedību ir vērts zināt, kad pielāgojat profilu. Dažas implementācijas dod priekšroku iniciatora secībai, citas pārkārto pēc vietējās politikas, tāpēc kopa, kas darbojas starp diviem piegādātājiem, var pazust kad apgriežat, kura puse sāk savienojumu.

AEAD noņem lauku, nevis pievieno to

AES-GCM un ChaCha20-Poly1305 autentificē un šifrē vienā operācijā. Kad kāds no tiem tiek izvēlēts ESP, integritātes algoritms netiek sarunāts atsevišķi, jo AEAD konstrukcija to jau sedz. Tāpēc priekšlikums, kas savieno AES-GCM ar SHA-256, labākajā gadījumā ir lieks, bet sliktākajā tiek noraidīts.

PRF IKE pusē joprojām ir atsevišķs, jo tas atvasina atslēgas vadības kanālam, nevis aizsargā lietderīgo slodzi. Tāpēc IKE priekšlikums var likumīgi apvienot AEAD šifru ar PRF un DH grupu, kamēr atbilstošais ESP priekšlikums uzskaita tikai AEAD šifru un neobligāto PFS grupu.

Atslēgas garums ir šifrēšanas marķiera daļa, tāpēc AES-128-GCM un AES-256-GCM ir atšķirīgi piedāvājumi. Profils, kas nokopēts no rokasgrāmatas, kura pieņēma 256-bit atslēgas, nesaskanēs ar 128-bit konfigurētu galapunktu, lai gan abas rindas saka AES-GCM. Divas puses var vienoties par šifru saimi un tomēr noraidīt viena otru domuzīmes skaitļa dēļ.

Lasiet instalēto SA, nevis konfigurāciju

Konfigurētais priekšlikumu saraksts ir piedāvājums; instalētā SA ir rezultāts. Uz strongSwan un Linux kodola ir pieejami abi skati:

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

swanctl --list-sas izdrukā sarunātos algoritmus katrai SA, tostarp to, vai CHILD izmanto AEAD. ip xfrm state parāda, ko kodols faktiski instalēja, un tieši tur apstiprina, ka atslēgu atjaunošana nav atkritusi uz citu kopu nekā dokumentētā.

Pēc labojuma saglabājiet šo izvadi blakus konfigurācijai. Kad klienta atjauninājums maina noklusējuma vērtības, fiksētā kopa dod jums bāzes līniju salīdzināšanai, un salīdzinājums norāda uz pārvietoto lauku, nevis sāk izmeklēšanu no jauna.