iPhone IKEv2 кон RouterOS: кој идентификатор каде припаѓа
Четири одделни тврдења одлучуваат за iOS IKEv2 тунел: бараната адреса, очекуваниот идентитет на серверот, тврдениот клиентски идентитет и сертификатниот материјал.
Доаѓањето до портата 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, на пример партнер IKEv2 со auth-method=digital-signature. Проверете ја вистинската содржина на менито во вашата инсталирана верзија, а не водич напишан за постара.
Тука несовпаѓањето е и најевтино за поправање, бидејќи портата може да ви го каже и идентитетот што го примила и идентитетот што го сакала. Проширувањето на прифатениот идентитет за да се смири грешката ја отстранува врската што му даваше смисла на поставувањето.
Проверете која фаза не успеала пред да уредите нешто
Прочитајте го обидот на двата краја и класифицирајте го пред да смените предлог. Несовпаѓање на предлогот, клуч за потпис што недостига, недоверлив издавач, погрешен идентификатор на партнер и одбиена авторизација на клиент — сето тоа изгледа како мртов тунел од телефонот, и секое има различен сопственик. Менувањето на сите пет поставки одеднаш гарантира дека од резултатот нема да научите ништо.
Запишете го претставениот идентитет, очекуваниот идентитет, издавачот и серискиот број на сертификатот и името на релевантната политика, држејќи ги приватните клучеви и тајните на профилот надвор од тој запис. Кога автентикацијата ќе успее, тестирајте приватна услуга и нејзиниот одговор, бидејќи доделувањето адреси, селекторите, DNS и политиката за пристап сѐ уште треба да работат откако размената IKE ќе заврши.