Always On VPN і VPN On Demand на iPhone: што разгортваць

On Demand адкрывае тунель пры супадзенні правілаў; кіраваны Always On прымусова трымае пакрыццё на падкантрольных прыладах. Кіраўніцтва, як выбраць адзін і даказаць, што ён працуе.

Два iPhone могуць абодва казаць VPN і паводзіць сябе зусім па-рознаму. On Demand адкрывае тунель, калі супадае правіла, і карыстальнік усё яшчэ можа выключыць яго ў Наладах. Кіраваны Always On трымае пакрыццё прымусова на падкантрольнай прыладзе, нават у моманты, калі тунель не можа ўзняцца. Выбірайце, пытаючыся, што павінна быць праўдай, калі карыстальнік нічога не робіць, а затым правярайце пераходы, а не ўстойлівы стан. Крокі ніжэй ідуць у тым парадку, у якім разгортванне сапраўды правальваецца.

Крок 1: вызначце, што прылада можа прымусіць

Always On — функцыя для падкантрольных прылад. Калі парк не пад кантролем, размова скончана яшчэ да пачатку, і ніякі ключ payload не робіць непадкантрольны тэлефон прымусовым. Пацвердзіце кантроль з боку кіравання і з самай прылады, затым пацвердзіце, хто падпісаў профіль.

На тэлефоне: Налады, затым Агульныя, затым VPN і Кіраванне прыладай. Запіс профілю называе ўладальніка, і асабісты профіль, усталяваны ўручную, выглядае інакш, чым дастаўлены сістэмай кіравання. Не рабіце выснову пра прымус з назвы профілю або маркетынгавай этыкеткі пастаўшчыка; этыкетка не з'яўляецца палітыкай платформы.

Запішыце тры факты перад тым, як кранаць канфігурацыю: пад кантролем ці не, кіраваны профіль ці асабісты, і які кліенцкі рэалізацыя нясе тунель. Кожны наступны крок залежыць ад гэтых трох, і перанос паводзін з асабістага тэлефона на кіраваны профіль — гэта шлях, якім разгортванне зацвярджаюць супраць няправільнай базы.

Крок 2: чытайце правілы on-demand, а не назву функцыі

On Demand — гэта спіс правілаў, якія ацэньваюцца па парадку. Кожнае правіла называе дзеянне і ўмовы, якія яго выбіраюць, і ўмовы — самая цікавая частка: тып інтэрфейсу, SSID Wi-Fi, суфікс дамена DNS або URL для праверкі. Набор правілаў, які ніколі не супадае, — гэта функцыя, якая ніколі не падключаецца.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Прачытайце ўвесь масіў і задайце два пытанні на кожнае правіла: ці можа гэтая ўмова калі-небудзь быць праўдай у гэтым парку, і што адбываецца, калі ніводнае правіла не супадае? Карпаратыўныя сеткі пераназываюць пункты доступу, аб'ядноўваюць SSID і змяняюць суфіксы DNS, і кожная такая змена моўчкі адрывае правіла ад рэальнасці.

Умова суфікса DNS найчасцей памылковая на практыцы, бо суфікс, які тэлефон паведамляе ў гасцявой сетцы, не той, які абслугоўвае карпаратыўны рэзалвер. Праверце імя, якое прылада сапраўды разрознівае, перш чым давяраць правілу.

Крок 3: правярайце пераходы, а не статычнае злучэнне

Тунель, які ўзняты, пакуль вы на яго глядзіце, даказвае няшмат. Выконвайце кожны пераход наўмысна і запісвайце, што робіць прылада, выкарыстоўваючы адзін і той жа прыватны рэсурс кожны раз, каб вынікі былі параўнальныя:

  • Далучыцеся да сеткі, дзе правіла павінна супасці, затым запытайце прыватны рэсурс і пацвердзіце, што ён загружаецца.
  • Пераключыцеся на сотавую сетку з дадаткам у фоне, затым вывядзіце яго наперад і паўтарыце запыт.
  • Падключыцеся да Wi-Fi з captive portal і паглядзіце, ці дасягальны партал, ці прымус блакуе яго да аўтэнтыфікацыі.
  • Адключыце тунель уручную на падкантрольнай прыладзе і праверце, ці вернецца ён сам і як хутка.

Выканайце той жа спіс на непадкантрольнай прыладзе, калі яна ёсць. Розніца паміж двума вынікамі — гэта рэальныя паводзіны разгортвання, і менавіта гэтага ніколі не пакажа здымак падключанага тунеля.

Крок 4: ведайце дзве формы адмовы

Прымусовае пакрыццё адмаўляе праз блакаванне. Калі тунель не ўстанаўліваецца, прылада губляе звычайны доступ у інтэрнэт разам з прыватнымі рэсурсамі, і карыстальнік бачыць тэлефон, які анлайн, але не можа праглядаць. Перападключэнне і блакаванне — асобныя назіранні, таму запісвайце абодва, а не стаўцеся да адсутнасці інтэрнэту як да аднаго сімптому.

On Demand адмаўляе тым, што не спрацоўвае. Правіла не супадае, тунель не з'яўляецца, і прыватны рэсурс проста сканчаецца па тайм-аўце. Гэта лёгка памылкова дыягнаставаць як праблему сервера, бо кліент паводзіць сябе менавіта так, як наладжаны.

Captive portal стаіць паміж імі: яму патрэбна злучэнне да таго, як існуе тунель, таму палітыка, якая блакуе ўсё да ўзняцця тунеля, патрабуе дакументаванага шляху праз партал. Вырашайце гэта ў дызайне, а не ў службе падтрымкі.

Крок 5: праверце, затым адпрацуйце адкат

Праверка належыць на рэальным шляху з бясшкодным трафікам: запытайце прыватны рэсурс, які не павінен быць публічным, пацвердзіце, які адрас прылада падае вонкі, і паўтарыце пасля перазагрузкі, каб вы бачылі паслядоўнасць запуску, а не толькі цёплы стан.

Затым адпрацуйце выдаленне на тэставай прыладзе, перш чым яно спатрэбіцца ў прадукцыі. Выдаленне профілю вяртае прыладу ў папярэдні стан, і веданне, колькі гэта займае і што бачыць карыстальнік, — частка runbook. Дапаможнік Apple па бяспецы VPN — гэта крыніца таго, што платформа дакументуе пра гэтыя палітыкі, і яго варта прачытаць перад напісаннем канфігурацыі, якая сцвярджае больш, чым платформа.

Трымайце тры факты з першага кроку побач з наборам правілаў і вынікамі тэстаў. Калі наступны чалавек спытае, чаму тэлефон падключаецца ў адной сетцы і не падключаецца ў іншай, гэтыя нататкі адкажуць за хвіліну замест перазборкі.

Падобныя артыкулы