IPsec təklifinə nə daxildir? IKE və ESP sahələri

IKE başlayır, hər iki tərəf AES-i elan edir, amma tunel yenə də NO_PROPOSAL_CHOSEN ilə uğursuz olur. Jurnal təklifin adını çəkir, lakin uyğun gəlməyən sahəni göstərmir. Təklif bir tam təklifdir və bir uyğunsuz sahə yalnız o sətri deyil, bütün kombinasiyanı etibarsız edir. Onu müstəqil alqoritm seçimləri dəsti kimi oxumaq uyğunsuzluğun görünməz qalmasının adi səbəbidir.

Ayrı təklif siyahıları olan iki danışıq

IKEv2 iki təhlükəsizlik assosiasiyası qurur. Birincisi nəzarət mübadiləsini özü qoruyan IKE SA, ikincisi isə trafikinizi ESP vasitəsilə daşıyan CHILD SA-dır. Hər birinin öz təklif siyahısı var və tərəf birini qəbul edib digərini rədd edə bilər.

Bu bölünmə geniş yayılmış bir çaşqınlığı izah edir: işləyən IKE SA yalnız nəzarət kanalı alqoritmlərinin uyğun gəldiyini sübut edir. Əgər CHILD təklifi uğursuz olarsa, birinci mərhələ tamamlansa və jurnallar yuxarıda sağlam görünsə də, tunel heç bir paket daşımır.

Hər siyahının daxilindəki sıra da vacibdir. Cavab verən tərəf təşəbbüskarın sıralanmış təkliflərindən seçir, buna görə geniş uyğun gələn qeydi dar olandan yuxarı qaldırmaq hansı dəstin quraşdırılacağını dəyişir, halbuki heç bir alqoritm adı dəyişmir. Bu sıranı defoltlara güvənmək əvəzinə konfiqurasiyada sabitləyin. Sabit sıra da saytlar arasında jurnal müqayisəsini mənalı edir.

Hansı sahələr hansı təklifə aiddir

Sahə çoxluğu kiçikdir, lakin iki danışıq arasında eyni deyil. Cədvəli sətir-sətir oxuyun, çünki bir sütundakı sahə digərində olmaya bilər. Sintaksis tətbiqdən asılı olaraq dəyişir; strongSwan-ın təklif sənədləri bir konkret mənbədir.

Şifrələmə sahəsi şifri və əksər sintaksislərdə açar uzunluğunu göstərir. Bütövlük sahəsi şifrə mətninin autentifikasiyası üçün istifadə olunan heşi, PRF isə IKE SA üçün açar materialı çıxaran funksiyanı göstərir. DH qrupu yeni ortaq sirr materialı yaradır, buna görə hər iki tərəfdə görünür, amma fərqli məqsədlərlə.

Genişləndirilmiş ardıcıllıq nömrələri yalnız məlumat yoluna aiddir. Onlar ardıcıllıq məkanını genişləndirir və CHILD təklifinin bir hissəsi kimi razılaşdırılır, buna görə oradakı uyğunsuzluq CHILD təklifini rədd edir, IKE SA isə toxunulmaz qalır.

Bir tam təklif necə seçilir

Hər təklif bir çoxluqdur və cavab verən tərəf hər məcburi sahənin qəbul edilə bilən olduğu çoxluq axtarır. İki siyahıda da AES və SHA-256 ola bilər və yenə də uyğun qeyd olmaya bilər, çünki açar uzunluğu, PRF və ya DH qrupu fərqlənir. Müqayisə hər alqoritm üzrə deyil, hər təklif üzrə aparılır.

Heç nə uyğun gəlmədikdə cavab verən tərəf uğursuz olan SA növü ilə NO_PROPOSAL_CHOSEN göndərir. Konfiqurasiyanı redaktə etməzdən əvvəl bildirişin hansı təklif siyahısına aid olduğunu oxuyun; IKE təklifi rədd edildiyi halda ESP alqoritmlərini dəyişmək ayırdetmə dövrünü boşa verir.

Profil tənzimləyərkən seçim davranışını bilmək faydalıdır. Bəzi tətbiqlər təşəbbüskarın sırasına üstünlük verir, digərləri yerli siyasətə görə yenidən sıralayır, buna görə iki satıcı arasında işləyən dəst yox ola bilər əlaqəni hansı tərəfin başlatdığını tərsinə çevirdikdə.

AEAD sahə əlavə etmir, sahə çıxarır

AES-GCM və ChaCha20-Poly1305 autentifikasiya və şifrələməni bir əməliyyatda edir. Onlardan biri ESP üçün seçildikdə bütövlük alqoritmi ayrıca razılaşdırılmır, çünki AEAD quruluşu onu artıq əhatə edir. Buna görə AES-GCM-i SHA-256 ilə birləşdirən təklif ən yaxşı halda artıqdır, ən pis halda rədd edilir.

PRF IKE tərəfində hələ də ayrıdır, çünki o, yükləri qorumaq əvəzinə nəzarət kanalı üçün açarlar çıxarır. Buna görə IKE təklifi AEAD şifrini PRF və DH qrupu ilə qanuni şəkildə birləşdirə bilər, uyğun ESP təklifi isə yalnız AEAD şifrini və istəyə bağlı PFS qrupunu sadalayır.

Açar uzunluğu şifrələmə tokeninin bir hissəsidir, buna görə AES-128-GCM və AES-256-GCM fərqli təkliflərdir. 256-bit açarları fərz edən bələdçidən köçürülmüş profil 128-bit açarlar üçün konfiqurasiya edilmiş son nöqtəyə uyğun gəlməyəcək, hər iki sətir AES-GCM yazsa da. İki tərəf şifr ailəsi barədə razılaşa və yenə də tiredən sonrakı rəqəm üzündən bir-birini rədd edə bilər.

Quraşdırılmış SA-nı oxuyun, konfiqurasiyanı yox

Konfiqurasiya edilmiş təklif siyahısı təklifdir; quraşdırılmış SA isə nəticədir. strongSwan və Linux nüvəsində hər iki görünüş mövcuddur:

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

swanctl --list-sas hər SA üzrə razılaşdırılmış alqoritmləri çap edir, o cümlədən CHILD-nin AEAD istifadə edib-etmədiyini. ip xfrm state nüvənin həqiqətən nə quraşdırdığını göstərir, bu da açar yenilənməsinin sənədləşdirdiyinizdən fərqli bir dəstə geri çəkilmədiyini təsdiqləmək üçün yerdir.

Düzəlişdən sonra bu çıxışı konfiqurasiyanın yanında saxlayın. Müştəri yeniləməsi defoltları dəyişdikdə, qeydə alınmış dəst müqayisə üçün baza verir və müqayisə araşdırmanı başdan başlamaq əvəzinə dəyişən sahəni göstərir.