VPN на iPad без запытаў пароля: сертыфікаты або захаваны ўваход
Захаваны пароль і сертыфікат прылады прыбіраюць запыт па-рознаму. Параўнайце іх і потым асобна вырашыце, што адкрывае тунэль.
«Спыніцеся пытаць у мяне пароль» насамрэч аб’ядноўвае тры патрабаванні ў адну скаргу, і разгортванне на iPad адказвае на іх у розных месцах. Запыт паходзіць ад аўтэнтыфікацыі, момант — ад актывацыі, а пакрыццё — ад прымусовага прымянення. Спачатку абярыце ўліковыя даныя, якія прыбіраюць запыт, а затым асобна вырашыце, што вызначае, калі адчыняецца тунэль. Змешванне гэтых двух рашэнняў — менавіта тое, праз што захаваны пароль апынаецца ў профілі, які ўсё роўна чакае націску.
| Saved or shared secret | Device certificate | |
|---|---|---|
| What the user sees | no prompt while the credential stays valid | no prompt, no password to rotate |
| What the admin manages | the secret in the profile and its distribution | enrollment, expiry and revocation per device |
| Typical failure | gateway demands a second factor | expired or revoked certificate |
Дзве праблемы ў адной скарзе
Убудаваная канфігурацыя IKEv2 на iPad можа спасылацца на пароль або на сертыфікат, і ключ AuthenticationMethod вырашае, што з гэтага прымяняецца, а PayloadCertificateUUID задае ўліковыя даныя, якія даюць ідэнтычнасць. Якія з іх прыме шлюз — пытанне палітыкі сервера, а не схільнасці кліента. Таму спачатку трэба высветліць, што дазваляе служба VPN, бо iPad не зможа дамовіцца да метаду, ад якога адмаўляецца іншы бок.
Толькі пасля гэтага мае сэнс гаварыць пра тое, калі актывуецца тунэль, а гэта зусім іншы набор ключоў профілю.
Варыянт першы: уліковыя даныя, якія iPad можа выкарыстаць паўторна
Захаваны пароль уліковага запісу або агульны сакрэт задавальняюць шлюз, які аўтэнтыфікуе карыстальніка ці групу, і прыбіраюць запыт, пакуль сакрэт застаецца сапраўдным. Яго слабасць — жыццёвы цыкл: сакрэт ляжыць у профілі, некалькі прылад могуць яго супольна выкарыстоўваць, а ратацыя азначае праўку кожнага профілю, дзе ён ёсць. Калі служба дадаткова патрабуе аднаразовы фактар або інтэрактыўнае пацверджанне, ніякая лакальная налада не ператворыць гэтую палітыку ва ўваход без удзелу карыстальніка.
Пароль, захаваны адной праграмай, таксама не становіцца аўтаматычна даступным іншай рэалізацыі VPN, таму той самы ўліковы запіс можа перастаць запытваць яго ў адным кліенце і запытваць кожны раз у іншым.
Варыянт другі: сертыфікат прылады з уласным ключом
Сертыфікат прыбірае запыт надзейней, бо iPad даказвае валоданне закрытым ключом, а не паўтарае сакрэт. Для гэтага патрэбна каб канчатковы сертыфікат і яго ключ паступілі па ўхваленым шляху рэгістрацыі, а шлюз прымаў аўтэнтыфікацыю па сертыфікаце для гэтага злучэння. Імпарт толькі сертыфіката CA дае прыладзе матэрыял даверу і больш нічога, і гэта частая і ціхая памылка.
Плата за гэта — праца з жыццёвым цыклам. Кожны iPad атрымлівае ўласную ідэнтычнасць, каб страчаную прыладу можна было адклікаць без перавыдання ўсяго парку, а даты заканчэння становяцца сапраўднымі аперацыйнымі падзеямі. Сертыфікат, які ціха заканчваецца, выглядае роўна як збой VPN той раніцай, калі гэта адбываецца.
Выбірайце па тым, што прымае шлюз, а не па схільнасці
Задайце адміністратару VPN два пытанні: якія метады аўтэнтыфікацыі служба прымае для гэтага тыпу кліента і ці нейкі з іх патрабуе інтэрактыўнага ўводу. Калі адказ — толькі сертыфікат, плануйце рэгістрацыю і падаўжэнне. Калі адказ — пароль плюс другі фактар, прыміце, што запыт гэта палітыка, і перастаньце лічыць яго няспраўнасцю прылады. Калі прынятыя абодва, сертыфікат выйграе па жыццёвым цыкле для кіраванага парку, а пароль — па працаёмкасці налады для некалькіх прылад.
Запішыце абраны метад у журнал разгортвання побач з ідэнтыфікатарам профілю, інакш наступны чалавек, які возьмецца за профіль, абярэ іншы.
Затым аддзяліце актывацыю ад аўтэнтыфікацыі
VPN On Demand адчыняе тунэль, калі супадае наладжаная ўмова — дамен DNS, тып інтэрфейсу ці далучаная сетка, і Apple апісвае гэта як тое, што не патрабуе ўзаемадзеяння з карыстальнікам. Гэта добра пасуе прыватным рэсурсам, якія павінны станавіцца даступнымі толькі тады, калі нешта іх запытвае. Гэта не тое самае, што кіраваны Always On, які трымае пакрыццё прымусова ўключаным і нясе ўласныя патрабаванні да нагляду і профілю.
Працоўныя ўліковыя даныя не дапамагаюць ні ў адным з варыянтаў. Многія iPad маюць цалкам спраўны сертыфікат і ўсё роўна чакаюць ручнога націску, бо ніякае правіла па патрабаванні не спрацавала.
Перадайце патрабаванне ў форме, з якой адміністратар можа працаваць: гэты iPad павінен дасягаць гэтых рэсурсаў без паўторнага ўводу карыстальніка, з гэтым тыпам уліковых даных і па гэтых правілах актывацыі і збою. Калі бягучая служба не можа выканаць гэтыя ўмовы, паўторныя запыты — гэта палітыка, якая працуе як задумана.