Kas įeina į IPsec pasiūlymą? IKE ir ESP laukai
Pasiūlymas yra vienas visas pasiūlymas, o ne algoritmų maišas. Pažiūrėkite, kurie laukai priklauso IKE, o kurie ESP, ir kodėl vienas neatitikimas atmeta visą rinkinį.
IKE prasideda, abi pusės skelbia AES, tačiau tunelis vis tiek žlunga su NO_PROPOSAL_CHOSEN. Žurnalas įvardija pasiūlymą, bet ne lauką, kuris nesutapo. Pasiūlymas yra vienas visas pasiūlymas, ir vienas nesuderinamas laukas panaikina visą derinį, o ne tik tą eilutę. Skaitymas jo kaip maišo nepriklausomų algoritmų pasirinkimų yra įprasta priežastis, kodėl neatitikimas lieka nematomas.
Dvi derybos su atskirais pasiūlymų sąrašais
IKEv2 sukuria dvi saugos asociacijas. Pirmoji yra IKE SA, kuri apsaugo patį valdymo pasikeitimą, o antroji yra CHILD SA, kuri perduoda jūsų srautą per ESP. Kiekviena turi savo pasiūlymų sąrašą, ir pusė gali priimti vieną ir atmesti kitą.
Šis atskyrimas paaiškina įprastą painiavą: veikianti IKE SA įrodo tik tai, kad valdymo kanalo algoritmai sutapo. Jei CHILD pasiūlymas žlunga, tunelis neperduoda nė vieno paketo, nors pirmoji fazė baigta ir žurnalai viršuje atrodo sveiki.
Tvarka kiekviename sąraše taip pat svarbi. Atsakantysis renkasi iš iniciatoriaus surikiuotų pasiūlymų, todėl plačiai suderinamo įrašo perkėlimas virš siauro pakeičia, kuris rinkinys bus įdiegtas, nekeičiant nė vieno algoritmo pavadinimo. Užfiksuokite tą tvarką konfigūracijoje, o ne pasikliaukite numatytosiomis reikšmėmis. Stabili tvarka taip pat padaro žurnalų palyginimą tarp svetainių prasmingą.
Kurie laukai priklauso kuriam pasiūlymui
Laukų rinkinys mažas, bet abiejose derybose jis nėra identiškas. Skaitykite lentelę eilutė po eilutės, nes vieno stulpelio lauko gali trūkti kitame. Sintaksė skiriasi priklausomai nuo įgyvendinimo; strongSwan pasiūlymų dokumentacija yra viena konkreti nuoroda.
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
Šifravimo laukas įvardija šifrą ir daugumoje sintaksių jo rakto ilgį. Integralumo laukas įvardija maišą, naudojamą šifruotam tekstui autentifikuoti, o PRF įvardija funkciją, kuri išveda raktinę medžiagą IKE SA. DH grupė sukuria naują bendrą slaptą medžiagą, todėl ji pasirodo abiejose pusėse, bet skirtingais tikslais.
Išplėstiniai sekos numeriai priklauso tik duomenų keliui. Jie praplečia sekos erdvę ir derinami kaip CHILD pasiūlymo dalis, todėl neatitikimas ten atmeta CHILD pasiūlymą, o IKE SA lieka nepaliesta.
Kaip parenkamas vienas visas pasiūlymas
Kiekvienas pasiūlymas yra rinkinys, o atsakantysis ieško rinkinio, kuriame kiekvienas privalomas laukas yra priimtinas. Du sąrašai gali abu turėti AES ir SHA-256 ir vis tiek neturėti jokio suderinamo įrašo, nes skiriasi rakto ilgis, PRF arba DH grupė. Palyginimas atliekamas pagal pasiūlymą, o ne pagal algoritmą.
Kai niekas nesutampa, atsakantysis siunčia NO_PROPOSAL_CHOSEN su nepavykusio SA tipu. Prieš redaguodami konfigūraciją perskaitykite, kurio pasiūlymų sąrašo tai susiję; ESP algoritmų keitimas, kai IKE pasiūlymas buvo atmestas, iššvaisto vieną derinimo ciklą.
Vertėtų žinoti pasirinkimo elgesį, kai derinate profilį. Kai kurie įgyvendinimai teikia pirmenybę iniciatoriaus tvarkai, kiti perrūšiuoja pagal vietinę politiką, todėl rinkinys, veikiantis tarp dviejų tiekėjų, gali išnykti kai apverčiate, kuri pusė pradeda ryšį.
AEAD pašalina lauką, o ne prideda jį
AES-GCM ir ChaCha20-Poly1305 autentifikuoja ir šifruoja vienoje operacijoje. Kai kuris nors iš jų pasirenkamas ESP, integralumo algoritmas atskirai nederinamas, nes AEAD konstrukcija jį jau apima. Todėl pasiūlymas, jungiantis AES-GCM su SHA-256, geriausiu atveju yra perteklinis, o blogiausiu – atmetamas.
PRF IKE pusėje vis dar atskiras, nes jis išveda raktus valdymo kanalui, o ne apsaugo naudingąją apkrovą. Štai kodėl IKE pasiūlymas gali teisėtai derinti AEAD šifrą su PRF ir DH grupe, o atitinkamas ESP pasiūlymas išvardija tik AEAD šifrą ir pasirenkamą PFS grupę.
Rakto ilgis yra šifravimo žetono dalis, todėl AES-128-GCM ir AES-256-GCM yra skirtingi pasiūlymai. Profilis, nukopijuotas iš vadovo, kuris darė prielaidą apie 256-bit raktus, nesutaps su 128-bit sukonfigūruotu galiniu tašku, nors abi eilutės sako AES-GCM. Dvi pusės gali susitarti dėl šifrų šeimos ir vis tiek atmesti viena kitą dėl skaičiaus po brūkšnelio.
Skaitykite įdiegtą SA, o ne konfigūraciją
Sukonfigūruotas pasiūlymų sąrašas yra pasiūlymas; įdiegta SA yra rezultatas. Su strongSwan ir Linux branduoliu prieinami abu vaizdai:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas išspausdina suderėtus algoritmus kiekvienai SA, įskaitant tai, ar CHILD naudoja AEAD. ip xfrm state parodo, ką branduolys iš tikrųjų įdiegė, ir čia patvirtinama, kad rakto atnaujinimas negrįžo prie kitokio rinkinio nei tas, kurį dokumentavote.
Po pataisymo išsaugokite šią išvestį šalia konfigūracijos. Kai kliento atnaujinimas pakeičia numatytąsias reikšmes, užfiksuotas rinkinys suteikia atskaitos liniją palyginimui, o palyginimas nurodo pasislinkusį lauką, o ne pradeda tyrimą iš naujo.