VPN sa iPad nang walang hiling na password: mga sertipiko o naka-save na pag-login

Ang «tigilan mo ang paghingi sa akin ng password» ay talagang pinagsasama ang tatlong pangangailangan sa isang reklamo, at ang pag-deploy sa iPad ay sumasagot sa kanila sa magkaibang lugar. Ang hiling ay nagmumula sa authentication, ang oras ay nagmumula sa activation, at ang saklaw ay nagmumula sa pagpapatupad. Piliin muna ang kredensyal na nag-aalis ng hiling, pagkatapos ay hiwalay na magpasya kung ano ang tumutukoy kung kailan bumubukas ang tunnel. Ang paghahalo ng dalawang desisyong ito ang dahilan kung bakit nagtatapos ang naka-save na password sa isang profile na naghihintay pa rin ng tapik.

Dalawang problema sa isang reklamo

Ang native na IKEv2 configuration sa iPad ay maaaring tumukoy sa password o sertipiko, at ang AuthenticationMethod na susi ang tumutukoy kung alin ang naaangkop, habang pinangalanan ng PayloadCertificateUUID ang kredensyal na nagbibigay ng pagkakakilanlan. Kung alin sa mga ito ang tatanggapin ng gateway ay tanong ng patakaran ng server, hindi kagustuhan ng kliyente. Kaya ang unang dapat itatag ay kung ano ang pinapayagan ng serbisyo ng VPN, dahil hindi makikipagnegosasyon ang iPad patungo sa paraang tinatanggihan ng kabilang dulo.

Pagkatapos lamang niyan may saysay na pag-usapan kung kailan nag-a-activate ang tunnel, na isang ganap na ibang set ng mga susi ng profile.

Unang opsyon: kredensyal na maaaring gamitin muli ng iPad

Ang naka-save na password ng account o pinagsamang lihim ay nagbibigay-kasiyahan sa gateway na nagpapatunay ng user o grupo, at inaalis nito ang hiling hangga't nananatiling wasto ang lihim. Ang kahinaan nito ay ang lifecycle: nasa profile ang lihim, maaaring ibahagi ito ng ilang device, at ang pag-ikot nito ay nangangahulugang paghawak sa bawat profile na nagdadala nito. Kung humihingi rin ang serbisyo ng one-time factor o interactive na pag-apruba, walang lokal na setting na gumagawa sa patakarang iyon na pag-login na walang pagmamatyag.

Ang password na na-save ng isang app ay hindi rin awtomatikong available sa ibang implementasyon ng VPN, kaya ang parehong account ay maaaring huminto sa paghingi sa isang kliyente at humingi sa bawat oras sa iba.

Ikalawang opsyon: sertipiko ng device na may sariling susi

Ang sertipiko ay nag-aalis ng hiling sa mas matibay na paraan, dahil pinatutunayan ng iPad ang paghawak ng pribadong susi sa halip na ulitin ang isang lihim. Kailangan nito na dumating ang dahong sertipiko at ang susi nito sa pamamagitan ng aprubadong landas ng enrollment, at tanggapin ng gateway ang authentication na may sertipiko para sa koneksyong iyon. Ang pag-import lamang ng CA certificate ay nagbibigay sa device ng trust material at wala nang iba, na karaniwan at tahimik na pagkabigo.

Ang kapalit ay trabaho sa lifecycle. Bawat iPad ay may sariling pagkakakilanlan upang ang nawawalang device ay maaaring bawiin nang hindi muling inilalabas ang buong fleet, at ang mga petsa ng pag-expire ay nagiging tunay na pangyayari sa operasyon. Ang sertipikong tahimik na nag-expire ay mukhang eksaktong isang pagkaantala ng VPN sa umagang nangyari ito.

Pumili ayon sa tinatanggap ng gateway, hindi ayon sa kagustuhan

Tanungin ang administrator ng VPN ng dalawang bagay: aling mga paraan ng authentication ang tinatanggap ng serbisyo para sa ganitong uri ng kliyente, at kung may isa sa kanila na nangangailangan ng interactive na input. Kung ang sagot ay sertipiko lamang, planuhin ang enrollment at renewal. Kung ang sagot ay password at pangalawang factor, tanggapin na patakaran ang hiling at itigil ang pagtrato dito bilang sira ng device. Kung pareho ang tinatanggap, panalo ang sertipiko sa lifecycle para sa pinamamahalaang fleet at ang password sa pagsisikap sa setup para sa ilang device.

Isulat ang napiling paraan sa talaan ng pag-deploy sa tabi ng identifier ng profile, dahil kung hindi, ang susunod na taong hahawak sa profile ay pipili ng iba.

Pagkatapos, paghiwalayin ang activation sa authentication

Binubuksan ng VPN On Demand ang tunnel kapag tumugma ang naka-configure na kundisyon, maging ito man ay DNS domain, uri ng interface o sinamahang network, at itinatala ito ng Apple bilang hindi nangangailangan ng interaksyon ng user. Angkop ito sa mga pribadong resource na dapat maging maabot lamang kapag may humihingi sa kanila. Hindi ito katulad ng pinamamahalaang Always On, na pinananatiling ipinatutupad ang saklaw at may sariling mga pangangailangan sa pangangasiwa at profile.

Ang gumaganang kredensyal ay walang ginagawa para sa alinman sa dalawa. Maraming iPad ang may ganap na maayos na sertipiko at naghihintay pa rin ng manu-manong tapik dahil walang panuntunang on-demand ang nasimulan.

Ipaabot ang pangangailangan sa anyong magagamit ng administrator: dapat maabot ng iPad na ito ang mga resource na ito nang walang paulit-ulit na input ng user, gamit ang ganitong uri ng kredensyal, at ayon sa mga panuntunang ito ng activation at pagkagambala. Kung hindi matugunan ng kasalukuyang serbisyo ang mga kundisyong iyon, ang paulit-ulit na hiling ay ang patakarang gumagana ayon sa disenyo.