Agordo de IKEv2-atestilo en iPhone: permana aŭ administrata aliĝo

Elekti RSA ĉar la atestila ilo de la enirejo uzas ĝin defaŭlte estas decido farita antaŭ la demando, kiu gravas: kiel ĉi tiuj iPhone estos aliĝitaj? Konekto tajpita de la uzanto kaj agorda profilo liverita de administrado montras malsamajn agordojn, kaj kelkaj atestilaj elektoj ekzistas nur sur unu el tiuj vojoj. Bone aranĝu la ordon kaj la atestila plano fariĝas mallonga; eraru kaj vi eldonos akreditilon, kiun la telefono ne uzos. Traktu la subajn paŝojn kiel sinsekvon, ĉar ĉiu mallarĝigas la elektojn disponeblajn por la sekva.

Paŝo unu: elektu la aliĝvojon

Permana agordo signifas, ke la uzanto entajpas la servilan adreson, elektas la aŭtentigan metodon kaj provizas ajnan akreditilon, kiun la interfaco permesas. Administrata aliĝo signifas, ke profilo portas la adreson, la identigilojn kaj referencon al akredita utilŝarĝo. La administrata vojo povas esprimi kombinaĵojn, kiujn la permana ekrano ne povas, kaj tial la atestila decido devas veni post ĉi tiu elekto, ne antaŭ ĝi.

Ambaŭ vojoj povas aŭtentigi telefonon. Ili diferencas en tio, kion vi povas agordi kaj kiu posedas la identecon, do elektu unu konscie anstataŭ miksi administritan profilon kun permana entajpo de akreditiloj.

Paŝo du: elektu algoritmojn por la vojo, kiun vi elektis

Por permane agorditaj iPhone, la notoj de strongSwan pri iOS-interfunkciado rekomendas RSA-servilan atestilon, ĉar la permana kliento eble ne akceptas ECDSA-servilan atestilon; la samaj notoj traktas macOS aparte. Legu tion kiel gvidadon por la subtenata klientaro, ne kiel permanentan leĝon pri Apple-aparatoj. Administrita profilo havas pli da loko: ĝi povas eksplicite elekti atestilan tipon, inkluzive de ECDSA-klienta identeco, kiam la utilŝarĝo kaj la enirejo ambaŭ subtenas ĝin.

Validigu la iOS-versiojn, kiujn vi efektive subtenas, antaŭ ol lanĉi ion ajn. Laboratoria telefono ĉe la plej nova eldono ne priskribas floton, kiu inkluzivas pli malnovajn aparatojn, kaj algoritmo, kiu funkcias en la laboratorio, povas tamen malsukcesi ĉe la plej malnova telefono sur la kampo. Prenu la version-gamuton el aparat-administrado, ne el memoro. Se la floto etendiĝas trans pluraj eldonoj, testu la plej malnovan unue, ĉar tie la permana interfaco estas plej limiga.

Paŝo tri: legu la profilkampojn kiel apartajn aferojn

Pluraj simile nomitaj ŝlosiloj priskribas malsamajn objektojn. La fora adreso estas la gastiganto, kiun la telefono alvokas. La fora identigilo estas la IKE-identeco, kiun ĝi atendas, ke la enirejo prezentu. La atestila referenco en la utilŝarĝo montras al klienta akreditilo, kaj la kampo pri atestila tipo elektas la tipon uzatan por IKEv2-maŝina aŭtentigado. Neniu el ili estas la subskriba algoritmo de la CA, kvankam la vortoj interkovriĝas.

La IKEv2-utilŝarĝa referenco de Apple listigas RSA kiel la defaŭltan atestilan tipon kun eksplicitaj ECDSA-variantoj, kaj ĝi ligas la eldonisto-noman ŝlosilon al apartaj aŭtentigaj agordoj. Legu tiujn rilatojn en la referenco por la metodo, kiun vi elektis, anstataŭ kopii unu ŝlosilon el funkcianta enkonduko.

Paŝo kvar: kongruigu la identecon de la enirejo kun ĝia atestilo

Uzu eksplicitan enirejan nomon, ekzemple vpn.example.com kaj metu kongruan alternativan subjektan nomon en la servilan atestilon. La Apple-gvidado de strongSwan ankaŭ atendas la plivastigitan ŝlosiluzon por servila aŭtentigado. Elekti RSA aŭ ECDSA ŝanĝas nenion el tio: algoritmo ne povas ripari nom-miskongruon, mankantan EKU aŭ nekompletan ĉenon.

Disdoni la fido-ankron estas aparta tasko de aserti la identecon. La telefono bezonas atestilan ĉenon, kiun ĝi povas validigi, kaj ĝi devas esti agordita atendi la nomon, kiun vi efektive metis en la atestilon.

Tio, ke alia platformo sukcese konektiĝas, estas pruvo pri la validigaj reguloj de tiu platformo, ne permeso malstreĉi la regulojn de la telefono. Tenu la kontrolojn identaj inter klientoj, krom se vi havas dokumentitan kialon diferenci.

Paŝo kvin: apartigu la klientan identecon de la CA-fido

Klienta atestilo kaj ĝia privata ŝlosilo ne estas la sama objekto kiel la CA-atestilo, kiun la telefono fidas. Enpakigi CA-atestilon ene de PKCS#12-identeco ne instalas ĝin aŭtomate kiel fido-ankron sur ĉiu subtenata aparato, do traktu fido-disdividon kiel propran paŝon kun propra kontrolo.

Se la dezajno anstataŭe uzas pasvort-bazitan EAP, la telefono bezonas la celitan kontan aŭtentigadon plus servilan validigadon. Tiu vojo ne pravigas sendi unu komunan privatan klientan ŝlosilon al la tuta floto, kio estas alia dezajno kun multe pli malbona fiaskmaniero.

Finu la planon kun renovigo kaj revokado en la menso: kiu reeldonas la klientan akreditilon, kiel la profilo ĝisdatiĝas, kaj kiel perdita telefono estas fortranĉata. Registru la profilan version kaj la aparatajn versiojn, kontraŭ kiuj vi validigis, ĉar tiu registro igas la sekvan atestilan rotacion rutina ŝanĝo.