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 могат също да носят ограничение за име на сертификат, което се оценява в допълнение към полетата за идентификатор. Прегледайте полезния товар, вместо да извеждате името за проверка от това, което показва екранът с настройки, защото двете не са една и същa настройка.
Проверете, че клиентският сертификат е ключ, а не само котва на доверие
Импортирането на CA сертификат дава на телефона нещо, с което да проверява шлюза. То не дава на телефона клиентска самоличност, а удостоверяването със сертификат изисква клиентския краен сертификат и неговия частен ключ, доставени заедно по одобрения път за регистрация. PKCS#12, създаден без частния ключ, произвежда профил, който се инсталира чисто и не удостоверява нищо.
Крайният клиентски сертификат също се нуждае от самоличност, която страната RouterOS очаква, което означава, че субектът или алтернативното име на субекта трябва да съвпадат със съответната конфигурация за самоличност. Издаването на клиентски и сървърни сертификати от един CA прави веригата удобна и не прави двата крайни сертификата взаимозаменяеми.
Проверете, че политиката на RouterOS приема това име
На шлюза записът за партньор задава режима на обмен и метода за удостоверяване, а записът за самоличност свързва приетата отдалечена самоличност със сертификат и с политиката, която следва. В RouterOS v7 тази двойка се изразява чрез записите за партньор и самоличност в IPsec, например партньор IKEv2 с auth-method=digital-signature. Проверявайте действителното съдържание на менюто във вашата инсталирана версия, а не ръководство, написано за по-стара.
Тук също несъответствието се поправя най-евтино, защото шлюзът може да ви каже както самоличността, която е получил, така и тази, която е искал. Разширяването на приетата самоличност, за да се заглуши грешката, премахва връзката, която е правела внедряването смислено.
Проверете кой етап се е провалил, преди да редактирате каквото и да е
Прочетете опита от двата края и го класифицирайте, преди да променяте предложение. Несъответствие в предложението, липсващ ключ за подписване, недоверен издател, грешен идентификатор на партньор и отказана клиентска оторизация — всички изглеждат от телефона като мъртъв тунел и всяко има различен собственик. Промяната на всичките пет настройки наведнъж гарантира, че няма да научите нищо от резултата.
Запишете представената самоличност, очакваната самоличност, издателя и серийния номер на сертификата и съответното име на политика, като държите частните ключове и тайните на профила извън този запис. След успешно удостоверяване тествайте частна услуга и отговора ѝ, защото назначаването на адреси, селекторите, DNS и политиката за достъп все още трябва да работят, след като обменът IKE приключи.