IPsec taklifi nimalardan iborat? IKE va ESP maydonlari
Taklif bitta to'liq taklifdir, algoritmlar qopchasi emas. Qaysi maydonlar IKE ga, qaysilari ESP ga tegishli ekanini va bitta nomuvofiqlik nega butun to'plamni rad etishini ko'ring.
IKE boshlanadi, ikki tomon ham AES e'lon qiladi, lekin tunnel baribir NO_PROPOSAL_CHOSEN bilan muvaffaqiyatsiz tugaydi. Jurnal taklif nomini aytadi, ammo mos kelmagan maydonni aytmaydi. Taklif bitta to'liq taklifdir va bitta mos kelmaydigan maydon faqat o'sha qatorni emas, butun birikmani bekor qiladi. Uni mustaqil algoritm tanlovlaridan iborat qopcha deb o'qish nomuvofiqlik ko'rinmay qolishining odatiy sababidir.
Alohida taklif ro'yxatlari bilan ikki muzokara
IKEv2 ikkita xavfsizlik birlashmasini quradi. Birinchisi boshqaruv almashinuvini o'zi himoya qiladigan IKE SA, ikkinchisi esa trafigingizni ESP orqali tashiydigan CHILD SA. Har birining o'z taklif ro'yxati bor va tomon bittasini qabul qilib, ikkinchisini rad etishi mumkin.
Bu bo'linish keng tarqalgan chalkashlikni tushuntiradi: ishlayotgan IKE SA faqat boshqaruv kanali algoritmlari mos kelganini isbotlaydi. Agar CHILD taklifi muvaffaqiyatsiz bo'lsa, birinchi bosqich tugagan va jurnallar yuqorida sog'lom ko'rinib turgan bo'lsa ham, tunnel bitta ham paket tashimaydi.
Har bir ro'yxat ichidagi tartib ham muhim. Javob beruvchi tashabbuskorning tartiblangan takliflaridan tanlaydi, shuning uchun keng mos keladigan yozuvni tor yozuvdan yuqoriga ko'chirish o'rnatiladigan to'plamni o'zgartiradi, biroq bitta ham algoritm nomi o'zgarmaydi. Bu tartibni standart qiymatlarga tayanmasdan konfiguratsiyada mahkamlang. Barqaror tartib saytlar orasidagi jurnal taqqoslashini ham mazmunli qiladi.
Qaysi maydonlar qaysi taklifga tegishli
Maydonlar to'plami kichik, lekin ikki muzokarada bir xil emas. Jadvalni qatorma-qator o'qing, chunki bir ustundagi maydon ikkinchisida bo'lmasligi mumkin. Sintaksis amalga oshirishga qarab farq qiladi; strongSwan takliflari hujjatlari bitta aniq manba.
| 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 |
Shifrlash maydoni shifrni va ko'p sintaksislarda uning kalit uzunligini bildiradi. Butunlik maydoni shifrlangan matnni autentifikatsiya qilish uchun ishlatiladigan xeshni bildiradi, PRF esa IKE SA uchun kalit materialini chiqaradigan funksiyani bildiradi. DH guruhi yangi umumiy maxfiy materialni o'rnatadi, shuning uchun u ikki tomonda ham ko'rinadi, lekin turli maqsadlarda.
Kengaytirilgan tartib raqamlari faqat ma'lumot yo'liga tegishli. Ular tartib fazosini kengaytiradi va CHILD taklifining qismi sifatida kelishiladi, shuning uchun u yerdagi nomuvofiqlik CHILD taklifini rad etadi, IKE SA esa tegilmagan holda qoladi.
Bitta to'liq taklif qanday tanlanadi
Har bir taklif to'plamdir va javob beruvchi har bir majburiy maydon maqbul bo'lgan to'plamni qidiradi. Ikki ro'yxat ham AES va SHA-256 ni o'z ichiga olishi va baribir mos keladigan yozuv bo'lmasligi mumkin, chunki kalit uzunligi, PRF yoki DH guruhi farq qiladi. Taqqoslash har bir algoritm bo'yicha emas, har bir taklif bo'yicha amalga oshiriladi.
Hech narsa mos kelmasa, javob beruvchi muvaffaqiyatsiz bo'lgan SA turi bilan NO_PROPOSAL_CHOSEN yuboradi. Konfiguratsiyani tahrirlashdan oldin bildirishnoma qaysi taklif ro'yxatiga tegishli ekanini o'qing; IKE taklifi rad etilganda ESP algoritmlarini o'zgartirish bitta disk raskadrovka siklini behuda sarflaydi.
Profilni sozlashda tanlov xulqini bilish foydali. Ba'zi amalga oshirishlar tashabbuskor tartibini afzal ko'radi, boshqalari mahalliy siyosat bo'yicha qayta tartiblaydi, shuning uchun ikki yetkazib beruvchi o'rtasida ishlaydigan to'plam yo'qolishi mumkin ulanishni qaysi tomon boshlashini almashtirganingizda.
AEAD maydonni qo'shish o'rniga olib tashlaydi
AES-GCM va ChaCha20-Poly1305 bitta operatsiyada autentifikatsiya va shifrlashni amalga oshiradi. Ulardan biri ESP uchun tanlansa, butunlik algoritmi alohida kelishilmaydi, chunki AEAD tuzilishi uni allaqachon qamrab oladi. Shuning uchun AES-GCM ni SHA-256 bilan juftlaydigan taklif eng yaxshi holatda ortiqcha, eng yomon holatda rad etiladi.
PRF IKE tomonida baribir alohida, chunki u yuklamalarni himoya qilish o'rniga boshqaruv kanali uchun kalitlar chiqaradi. Shuning uchun IKE taklifi AEAD shifrini PRF va DH guruhi bilan qonuniy ravishda birlashtira oladi, mos keladigan ESP taklifi esa faqat AEAD shifrini va ixtiyoriy PFS guruhini sanab o'tadi.
Kalit uzunligi shifrlash tokenining qismi, shuning uchun AES-128-GCM va AES-256-GCM turli takliflardir. 256-bit kalitlarni nazarda tutgan qo'llanmadan ko'chirilgan profil 128-bit uchun sozlangan so'nggi nuqtaga mos kelmaydi, garchi ikkala qator ham AES-GCM desa ham. Ikki tomon shifrlar oilasida kelishishi va baribir chiziqchadan keyingi raqam tufayli bir-birini rad etishi mumkin.
Konfiguratsiyani emas, o'rnatilgan SA ni o'qing
Sozlangan taklif ro'yxati taklifdir; o'rnatilgan SA natijadir. strongSwan va Linux yadrosida ikkala ko'rinish ham mavjud:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas har bir SA uchun kelishilgan algoritmlarni chop etadi, CHILD AEAD ishlatadimi-yo'qmi ham qo'shilgan. ip xfrm state yadro aslida nima o'rnatganini ko'rsatadi, va kalit yangilanishi siz hujjatlashtirgandan boshqa to'plamga qaytmaganini tasdiqlaydigan joy aynan shu.
Tuzatishdan keyin bu chiqishni konfiguratsiya yonida saqlang. Mijoz yangilanishi standart qiymatlarni o'zgartirganda, yozib olingan to'plam sizga taqqoslash uchun tayanch chiziq beradi va taqqoslash tekshiruvni boshidan boshlash o'rniga siljigan maydonni ko'rsatadi.