iPhone-да IKEv2 сертификатын орнату: қолмен немесе басқарылатын тіркеу

RSA-ны шлюздің сертификат құралы әдепкі бойынша қолданады деп таңдау — бұл маңызды сұраққа дейін қабылданатын шешім: бұл iPhone құрылғылары қалай тіркеледі? Пайдаланушы өзі енгізген қосылым мен басқару тарататын конфигурация профилі әртүрлі параметрлер ұсынады, ал кейбір сертификат таңдаулары осы жолдардың тек біреуінде ғана бар. Ретті дұрыс құрсаңыз, сертификат жоспары қысқарады; қателессеңіз, телефон пайдаланбайтын тіркелгі деректерін шығарасыз. Төмендегі қадамдарды реттілік ретінде қарастырыңыз, өйткені әрқайсысы келесіге қолжетімді таңдауларды тарылтады.

Бірінші қадам: тіркеу жолын таңдаңыз

Қолмен конфигурациялау пайдаланушының сервер мекенжайын енгізіп, аутентификация әдісін таңдап, интерфейс рұқсат ететін кез келген тіркелгі деректерін ұсынатынын білдіреді. Басқарылатын тіркеу профильдің мекенжайды, идентификаторларды және тіркелгі деректерінің пайдалы жүктемесіне сілтемені алып жүретінін білдіреді. Басқарылатын жол қолмен экран көрсете алмайтын комбинацияларды білдіре алады, сондықтан сертификат туралы шешім осы таңдаудан кейін келуі керек, оған дейін емес.

Екі жол да телефонды аутентификациялай алады. Олар нені конфигурациялауға болатынымен және идентитет кімге тиесілі екенімен ерекшеленеді, сондықтан басқарылатын профильді қолмен тіркелгі деректерін енгізумен араластырудың орнына біреуін әдейі таңдаңыз.

Екінші қадам: таңдаған жолыңыз үшін алгоритмдерді таңдаңыз

Қолмен конфигурацияланған iPhone үшін strongSwan-ның iOS үйлесімділік жазбалары RSA серверлік сертификатын ұсынады, өйткені қолмен клиент ECDSA серверлік сертификатын қабылдамауы мүмкін; сол жазбалар macOS-ты бөлек қарастырады. Мұны қолдау көрсетілетін клиенттер жиынтығына арналған нұсқаулық деп оқыңыз, Apple құрылғылары туралы мәңгілік заң деп емес. Басқарылатын профильдің мүмкіндігі көбірек: пайдалы жүктеме мен шлюз екеуі де қолдаса, ол сертификат түрін анық таңдай алады, оның ішінде ECDSA клиенттік идентитетін.

Бірдеңе орналастырмас бұрын өзіңіз шынымен қолдайтын iOS нұсқаларын тексеріңіз. Ең жаңа шығарылымдағы зертханалық телефон ескі құрылғыларды қамтитын парканы сипаттамайды, ал зертханада жұмыс істейтін алгоритм даладағы ең ескі телефонда сәтсіздікке ұшырауы мүмкін. Нұсқа ауқымын жадтан емес, құрылғыларды басқарудан алыңыз. Егер парк бірнеше шығарылымды қамтыса, әуелі ең ескісін сынаңыз, өйткені қолмен интерфейс дәл сол жерде ең шектеулі.

Үшінші қадам: профиль өрістерін жеке нәрселер ретінде оқыңыз

Ұқсас атаулы бірнеше кілт әртүрлі нысандарды сипаттайды. Қашықтағы мекенжай — телефон қоңырау шалатын хост. Қашықтағы идентификатор — шлюз ұсынады деп күтілетін IKE идентитеті. Пайдалы жүктеменің сертификат сілтемесі клиент тіркелгі деректерін, ал сертификат түрі өрісі IKEv2 машиналық аутентификациясы үшін қолданылатын түрді таңдайды. Олардың ешқайсысы CA қолтаңба алгоритмі емес, дегенмен сөздер қабаттасады.

Apple-дың IKEv2 пайдалы жүктеме анықтамасы RSA-ны анық ECDSA нұсқаларымен әдепкі сертификат түрі ретінде тізіп, шығарушы атауының кілтін белгілі бір аутентификация параметрлерімен байланыстырады. Бұл қатынастарды жұмыс істеп тұрған орналастырудан бір кілт көшірудің орнына таңдаған әдісіңіздің анықтамасынан оқыңыз.

Төртінші қадам: шлюз идентитетін оның сертификатына сәйкестендіріңіз

Анық шлюз атауын қолданыңыз, мысалы vpn.example.com және сервер сертификатына сәйкес келетін балама субъект атауын қойыңыз. strongSwan-ның Apple нұсқаулығы сервер аутентификациясы үшін кеңейтілген кілт пайдалануын да күтеді. RSA немесе ECDSA таңдау мұның ешбірін өзгертпейді: алгоритм атау сәйкессіздігін, жетіспейтін EKU-ды немесе толық емес тізбекті түзете алмайды.

Сенім тірегін тарату идентитетті растаудан бөлек міндет. Телефонға ол тексере алатын сертификат тізбегі қажет және ол сертификатқа шынымен қойған атауды күтуге конфигурациялануы керек.

Басқа платформаның сәтті қосылуы сол платформаның тексеру ережелері туралы дәлел, телефонның ережелерін босаңсытуға рұқсат емес. Ерекшеленуге құжатталған себебіңіз болмаса, тексерулерді клиенттер арасында бірдей ұстаңыз.

Бесінші қадам: клиент идентитетін CA сенімінен бөліңіз

Клиент сертификаты мен оның жеке кілті телефон сенетін CA сертификатымен бір нысан емес. CA сертификатын PKCS#12 идентитетінің ішіне бумалау оны қолдау көрсетілетін әрбір құрылғыда сенім тірегі ретінде автоматты түрде орнатпайды, сондықтан сенімді таратуды өзіндік тексеруі бар жеке қадам ретінде қарастырыңыз.

Егер дизайн оның орнына құпиясөзге негізделген EAP қолданса, телефонға көзделген тіркелгі аутентификациясы және серверді тексеру қажет. Бұл жол бүкіл паркаға бір ортақ клиент жеке кілтін жіберуді ақтамайды, бұл басқа дизайн және әлдеқайда нашар сәтсіздік режиміне ие.

Жоспарды жаңарту мен кері қайтаруды ескере отырып аяқтаңыз: клиент тіркелгі деректерін кім қайта шығарады, профиль қалай жаңартылады және жоғалған телефон қалай ажыратылады. Профиль нұсқасын және тексерген құрылғы нұсқаларын жазып алыңыз, өйткені дәл сол жазба келесі сертификат ауыстыруды күнделікті жұмысқа айналдырады.