iPhone IKEv2-dən RouterOS-a: hansı identifikator hara gedir
Dörd ayrı iddia iOS IKEv2 tunelini müəyyən edir: yığılan ünvan, gözlənilən server kimliyi, iddia edilən müştəri kimliyi və sertifikat materialı.
MikroTik şlüzünə çatmaq IKEv2 yerləşdirməsinin yalnız nəqliyyat yarısını həll edir, başqa heç nəyi. Sonra dörd ayrı iddia tunelin yaranıb-yaranmayacağını müəyyən edir: telefonun yığdığı ünvan, gözlədiyi server kimliyi, özü üçün iddia etdiyi kimlik və bu iddianı dayaqlandıran sertifikat materialı. Onları bu sıra ilə yoxlayın və şlüzün təqdim etdiyi ilə uyğun gəlməyən birincisində dayanın. Hər biri ayrı yerdə redaktə olunur, buna görə səhv redaktə adətən nasazlığı düzəltmək əvəzinə yerini dəyişir.
| Setting | What it decides | What it has to agree with |
|---|---|---|
| Remote address | where IKE packets are sent | a reachable name or address for the gateway |
| Remote Identifier | which server identity is expected | the gateway certificate name and the peer identity RouterOS presents |
| Local Identifier | who the phone claims to be | the client certificate name and the RouterOS identity entry |
| Certificate payload | trust plus proof of key possession | the issuing chain and a usable client private key |
Profil sahələrini mübadilənin onlardan istifadə etdiyi sıra ilə yoxlayın
Uzaq ünvan ilk IKE paketinin təyinatıdır və başqa heç nə deyil. Uzaq identifikator telefonun şlüzün özünü təsdiqləməsini gözlədiyi şeydir və bu, marşrut deyil, addır. Hər ikisini eyni host adı ilə doldurmaq, şlüz sertifikatı bu adı daşıyırsa işləyir və daşımırsa marşrut problemi kimi görünən şəkildə uğursuz olur. Profili doldurulacaq sahələr siyahısı kimi deyil, iddialar ardıcıllığı kimi oxuyun.
Yerli identifikator telefonun öz iddiasıdır və telefonun təqdim etdiyi müştəri sertifikatı üçün RouterOS kimlik qeydinin qəbul etdiyi ad olmalıdır. İkisi uyğun gəlmirsə, şlüz sertifikatın özü təsdiqləndikdən sonra bağlantını rədd edir və jurnal adlandırma deyil, avtorizasiya problemi kimi görünür.
İdentifikatorları şlüzün təqdim etdiyi ilə müqayisə edin
Sertifikat autentifikasiyası üçün qurulmuş RouterOS peer qeydi öz sertifikatını təqdim edir və kimliyi, başqa cür qurulmayıbsa, həmin sertifikatdan götürülür. Telefonun Uzaq identifikatoru şlüzün DNS adını göstərirsə, şlüz sertifikatının həmin ada telefonun qəbul edəcəyi yerdə — adətən subyektin alternativ adında — ehtiyacı var. Fərqli ümumi ad üçün verilmiş sertifikat, açar və zəncir mükəmməl olsa da, yoxlamadan keçməyəcək.
İdarə olunan Apple profilləri identifikator sahələrinə əlavə olaraq qiymətləndirilən sertifikat adı məhdudiyyəti də daşıya bilər. Yoxlama adını parametrlər ekranının göstərdiyindən çıxarmaq əvəzinə yükü yoxlayın, çünki ikisi eyni parametr deyil.
Müştəri sertifikatının sadəcə etimad ankeri deyil, açar olduğunu yoxlayın
CA sertifikatını idxal etmək telefona şlüzü yoxlamaq üçün bir şey verir. Telefona müştəri kimliyi vermir və sertifikat autentifikasiyası müştəri yarpaq sertifikatının və onun şəxsi açarının təsdiqlənmiş qeydiyyat yolu ilə birlikdə çatdırılmasını tələb edir. Şəxsi açar olmadan qurulmuş PKCS#12 təmiz quraşdırılan və heç nəyi autentifikasiya etməyən profil yaradır.
Müştəri yarpağı həm də RouterOS tərəfinin gözlədiyi kimliyə ehtiyac duyur, yəni subyekt və ya subyektin alternativ adı uyğun kimlik konfiqurasiyası ilə üst-üstə düşməlidir. Müştəri və server sertifikatlarını bir CA-dan vermək zənciri rahat edir, amma iki yarpağı bir-birini əvəz edən etmir.
RouterOS siyasətinin bu adı qəbul etdiyini yoxlayın
Şlüzdə peer qeydi mübadilə rejimini və autentifikasiya metodunu təyin edir, kimlik qeydi isə qəbul edilən uzaq kimliyi sertifikata və ondan sonra gələn siyasətə bağlayır. RouterOS v7-də bu cütlük IPsec peer və kimlik qeydləri ilə ifadə olunur, məsələn auth-method=digital-signature olan IKEv2 peer ilə. Köhnə versiya üçün yazılmış bələdçi əvəzinə quraşdırılmış buraxılışınızdakı faktiki menyu məzmununu yoxlayın.
Uyğunsuzluğu düzəltməyin ən ucuz yeri də buradır, çünki şlüz sizə həm aldığı kimliyi, həm istədiyi kimliyi deyə bilər. Xətanı susdurmaq üçün qəbul edilən kimliyi genişləndirmək yerləşdirməni mənalı edən bağı aradan qaldırır.
Nəyisə redaktə etməzdən əvvəl hansı mərhələnin uğursuz olduğunu yoxlayın
Cəhdi hər iki tərəfdə oxuyun və təklifi dəyişməzdən əvvəl təsnif edin. Təklif uyğunsuzluğu, çatışmayan imzalama açarı, etibarsız verən, səhv peer identifikatoru və rədd edilən müştəri avtorizasiyası telefondan hamısı ölü tunel kimi görünür və hər birinin sahibi fərqlidir. Beş parametrin hamısını birdən dəyişmək nəticədən heç nə öyrənməyəcəyinizə zəmanət verir.
Təqdim edilən kimliyi, gözlənilən kimliyi, sertifikatın verənini və seriya nömrəsini, həmçinin müvafiq siyasət adını qeyd edin, şəxsi açarları və profil sirlərini bu qeyddən kənarda saxlayın. Autentifikasiya uğurlu olduqdan sonra şəxsi xidməti və cavabını sınayın, çünki ünvan təyini, selektorlar, DNS və giriş siyasəti IKE mübadiləsi bitdikdən sonra da işləməlidir.