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, напрыклад партнёр IKEv2 з auth-method=digital-signature. Правярайце фактычны змест меню ў вашай усталяванай версіі, а не інструкцыю, напісаную для старэйшай.
Тут жа неадпаведнасць танней за ўсё выправіць, бо шлюз можа паведаміць вам і ідэнтычнасць, якую атрымаў, і ідэнтычнасць, якую хацеў. Пашырэнне прынятай ідэнтычнасці, каб заглушыць памылку, прыбірае сувязь, якая надавала разгортванню сэнс.
Праверце, на якім этапе адбыўся збой, перш чым нешта рэдагаваць
Прачытайце спробу на абодвух канцах і класіфікуйце яе, перш чым мяняць прапанову. Неадпаведнасць прапановы, адсутны ключ подпісу, недавераны выдавец, няправільны ідэнтыфікатар партнёра і адхіленая аўтарызацыя кліента — усё гэта выглядае з тэлефона як мёртвы тунель, і ў кожнага свая гаспадарка. Змяніць усе пяць налад адразу — гарантыя, што вы нічога не даведаецеся з выніку.
Запішыце прад'яўленую ідэнтычнасць, чаканую ідэнтычнасць, выдаўцу і серыйны нумар сертыфіката і адпаведную назву палітыкі, трымаючы прыватныя ключы і сакрэты профілю па-за гэтым запісам. Пасля паспяховай аўтэнтыфікацыі праверце прыватную службу і яе адказ, бо прызначэнне адрасоў, селектары, DNS і палітыка доступу ўсё яшчэ павінны працаваць пасля завяршэння абмену IKE.