iPhone IKEv2 ка RouterOS: који идентификатор где иде
Четири одвојене тврдње одлучују о IKEv2 тунелу на iOS-у: бирана адреса, очекивани идентитет сервера, тврђени идентитет клијента и сертификатни материјал.
Долазак до MikroTik пролаза решава само транспортну половину IKEv2 примене и ништа више. Затим четири одвојене тврдње одлучују да ли ће тунел настати: адреса коју телефон бира, идентитет сервера који очекује, идентитет који тврди за себе и сертификатни материјал који подупире ту тврдњу. Проверавајте их тим редоследом и зауставите се на првој која се не слаже са оним што пролаз представља. Свака се уређује на другом месту, због чега погрешна измена обично премешта квар уместо да га поправи.
| 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 |
Проверите поља профила редом којим их размена користи
Удаљена адреса је одредиште првог IKE пакета и ништа више. Удаљени идентификатор је оно за шта телефон очекује да ће пролаз доказати да јесте, и то је име, а не рута. Попуњавање оба истим именом хоста функционише када сертификат пролаза носи то име, а не успева на начин који изгледа као проблем рутирања када га не носи. Читајте профил као след тврдњи, а не као списак поља за попуњавање.
Локални идентификатор је сопствена тврдња телефона и мора бити име које RouterOS запис идентитета прихвата за клијентски сертификат који телефон представља. Ако се њих двоје не слажу, пролаз одбија везу након што је сам сертификат валидиран, а дневник изгледа као проблем ауторизације, а не именовања.
Проверите идентификаторе према ономе што пролаз представља
RouterOS запис партнера конфигуриран за аутентификацију сертификатом представља сопствени сертификат, а његов идентитет се црпи из тог сертификата осим ако нисте конфигурисали другачије. Ако удаљени идентификатор телефона именује DNS име пролаза, сертификат пролаза треба то име на месту које ће телефон прихватити, обично у алтернативном имену субјекта. Сертификат издат за друго уобичајено име неће проћи валидацију иако су кључ и ланац савршени.
Управљани Apple профили могу носити и ограничење имена сертификата које се оцењује уз поља идентификатора. Прегледајте садржај уместо да име за валидацију закључујете из онога што приказује екран подешавања, јер то нису иста подешавања.
Проверите да је клијентски сертификат кључ, а не само сидро поверења
Увоз CA сертификата даје телефону нешто чиме може валидирати пролаз. Не даје му клијентски идентитет, а аутентификација сертификатом захтева клијентски завршни сертификат и његов приватни кључ достављене заједно одобреним путем уписа. PKCS#12 изграђен без приватног кључа даје профил који се чисто инсталира и ништа не аутентификује.
Завршни клијентски сертификат такође треба идентитет који RouterOS страна очекује, што значи да се субјекат или алтернативно име субјекта мора поклопити са одговарајућом конфигурацијом идентитета. Издавање клијентских и серверских сертификата из једног CA чини ланац практичним и не чини та два завршна сертификата заменљивим.
Проверите да ли RouterOS политика прихвата то име
На пролазу запис партнера поставља начин размене и методу аутентификације, а запис идентитета повезује прихваћени удаљени идентитет са сертификатом и са политиком која следи. У RouterOS v7 тај пар се изражава кроз IPsec записe партнера и идентитета, на пример партнер IKEv2 са auth-method=digital-signature. Проверите стварни садржај менија на инсталираној верзији, а не водич написан за старију.
Овде је и неслагање најјефтиније поправити, јер вам пролаз може рећи и идентитет који је примио и идентитет који је желео. Проширивање прихваћеног идентитета да би се грешка утишала уклања везу која је примени давала смисао.
Проверите која је фаза пала пре него што било шта уредите
Прочитајте покушај на оба краја и класификујте га пре него што промените предлог. Неслагање предлога, кључ за потпис који недостаје, неповерљив издавач, погрешан идентификатор партнера и одбијена ауторизација клијента сви изгледају као мртав тунел са телефона, и сваки има другог власника. Промена свих пет подешавања одједном гарантује да из резултата нећете научити ништа.
Забележите представљени идентитет, очекивани идентитет, издавача и серијски број сертификата и назив релевантне политике, држећи приватне кључеве и тајне профила изван тог записа. Када аутентификација успе, тестирајте приватну услугу и њен одговор, јер додела адреса, селектори, DNS и политика приступа још морају да раде након што се IKE размена заврши.