Windows və FortiGate üzərində IKEv2: insanların birləşdirdiyi üç parametr
IKE açar mübadiləsi, CHILD SA qorunması və həmkar autentifikasiyası üç ayrı sətirdir. İki dialoqda uyğun gələn qrup nömrələri onları birləşdirmir.
Windows klienti ilə FortiGate şlüzü arasında IKEv2 razılaşması uğursuz olmaqda davam edir və uyğun olmayan nömrənin axtarışı daha uzun bir nömrə siyahısı yaradır. Siyahı yalnız o zaman idarəolunan olur ki, o, müstəqil şəkildə uğursuz olan üç sətrə bölünsün: IKE-ni qoruyan açar mübadiləsi, CHILD SA-ya tətbiq olunan qoruma və hər tərəfin kim olduğunu sübut edən autentifikasiya. Qrup nömrələri bu sətirlərdən ikisində görünür və fərqli məna daşıyır.
Müstəqil uğursuz olan üç sətir
Birinci sətir IKE-nin öz daxilindəki açar mübadiləsidir və danışıqları qoruyan açarları yaradır. İkincisi CHILD SA üçün təklifdir və tunelin daşıdığı trafiki qoruyur. Üçüncüsü autentifikasiyadır və hər tərəfin nə təqdim etdiyini və digərinin bunu necə yoxladığını müəyyən edir.
Uğursuzluqlar müxtəlif yerlərə düşür. Mübadilə uğursuzluğu hələ heç bir tunel yoxkən danışıqları dayandırır. CHILD SA uğursuzluğu autentifikasiya uğurlu olduqdan sonra baş verir, bəzən yalnız açarlar yenilənərkən. Autentifikasiya uğursuzluğu jurnallarda mübadilə uğursuzluğu kimi görünə bilər, əgər yalnız ilk xətanı oxusunuz.
Sətirləri ayırmaq mühasibat işi deyil. Bu, hansı parametrin dəyişdirilməyə dəyər olduğunu dəyişir və bu sahədə ən bahalı addımın, yəni təklif uyğunsuzluğunu düzəltmək üçün işlək sertifikatların yenidən yaradılmasının qarşısını alır. Bir sətrin dəyişməsi heç vaxt digər ikisini onunla birlikdə dəyişməyə məcbur etməməlidir. Bu müstəqillik onları ayrı-ayrı yazmağın bütün məqsədidir.
Windows-un iki sahəsi nəyə nəzarət edir
Windows iki sahəni ayrı saxlayır: DHGroup IKE mübadiləsini özünü konfiqurasiya edir, PfsGroup isə tuneldən keçən trafiki qoruyan IPsec siyasətini konfiqurasiya edir. Onlar müxtəlif fazalara aiddir. Windows-un IKE sahəsini FortiGate-in 2-ci faza dəyəri ilə müqayisə etmək səhv cütü yoxlayır və nömrələr uyğun gələ bilər, halbuki əsas mübadilə hələ də uğursuz olur.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAİkinci və üçüncü əmrlər həqiqətən mövcud olan təhlükəsizlik assosiasiyalarını göstərir və bu, klientin verə biləcəyi cavaba ən yaxın şeydir. Əsas rejim assosiasiyası olub sürətli rejim assosiasiyası olmaması CHILD SA problemidir və bu, sertifikat problemi deyil, 2-ci faza uyğunsuzluğunun əlamətidir.
Bir cəhddə nə təklif olunduğunu və nə seçildiyini qeyd edin. Məqbul təklifi ehtiva edən təklif siyahısı ilə şlüzün siyasətinə uyğun gəlməyən seçilmiş təklif konfiqurasiya fərqidir, interoperabellik sirri deyil.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
Elliptik əyri qrupu imza açarınızı seçmir
Bu sahədə ən davamlı yanlış nəticə elliptik əyri DH qrupunun seçilməsinin elliptik əyri sertifikatı tələb etməsi fikridir. DH qrupu açar mübadiləsi materialı verir; imza alqoritmi autentifikasiya çərçivəsi tərəfindən razılaşdırılır və bunlar IKEv2-də ayrı qərarlardır.
RFC 7427 məhz ona görə mövcuddur ki, bu qərarlar əvvəllər bir-birinə bağlı idi və imza alqoritmlərinin açar mübadiləsindən asılı olmadan necə elan edilib seçildiyini müəyyən edir. Şlüz eyni zamanda həm əyri qrupunu, həm də imza sxemləri seçimini dəstəkləyə bilər.
Beləliklə, qrup dəyişikliyindən sonra danışıqlar uğursuz olursa, sertifikatın açar növünə baxmazdan əvvəl autentifikasiya metoduna baxın. Sertifikatı dəyişmək yavaş və riskli əməliyyatdır və nadir hallarda cavabdır; bunu ilk növbədə etmək hansı dəyişikliyin həqiqətən kömək etdiyini anlamaq qabiliyyətinizi məhv edir. Sertifikat anbarına toxunmazdan əvvəl autentifikasiya sətrini oxuyun.
İkisini razılaşma vərəqinin ayrı sətirlərində saxlayın və səhv cəlbedici olmaqdan çıxar. Bir sətir qrupları, digəri imza sxemlərini və kimlikləri sadalayır və heç biri digəri haqqında sübut deyil.
Hər şəxsi açarı həqiqi sahibi ilə birlikdə qoyun
Öz sertifikatını təqdim edən şlüz onunla uyğun gələn şəxsi açara ehtiyac duyur. Zənciri yoxlayan həmkar CA sertifikatına ehtiyac duyur və xüsusilə CA-nın imza açarına ehtiyac duymur. Bu üç elementi qarışdırmaq insanların sertifikatın başqa kateqoriyada görünməsi üçün VPN cihazına CA şəxsi açarını idxal etməsi ilə nəticələnir.
FortiOS-da rollar fərqlidir: açarı ilə birlikdə yerli sertifikat, həmkarı müəyyən etmək üçün istifadə olunan uzaq sertifikat və həmin CA-nın imzaladığı sertifikatlara etimad yaradan uzaq CA qeydi. Şəxsi açarı olmayan uzaq CA qeydi natamam deyil; o, öz məqsədi üçün düzgündür.
İdxal edilmiş CA imza açarları həmin cihazı oxuya bilən hər kəsin səlahiyyətini genişləndirir. Onlar adi həmkar yoxlamasını da həll etmir, çünki yoxlama üçün açıq sertifikat və etimad qərarı lazımdır, yeni sertifikat yaratmaq qabiliyyəti deyil.
CA imza açarını emissiyanın öz prosesində saxlayın və hansı cihazın hansı açarı saxladığını qeyd edin. Sahiblərin qısa cədvəli audit kimin kimin adına çıxış edə biləcəyini soruşduqda alqoritmlərin daha uzun cədvəlindən dəyərlidir. Heç kim yalnız inventar üçün olduğunu bildiyi açarı idxal etmir. İnventarı hadisədən əvvəl yazın, sonra deyil.