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 је листа правила која се оцењују по реду. Свако правило наводи акцију и услове који га бирају, а услови су занимљиви део: тип интерфејса, Wi-Fi SSID, 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 суфикса је онај који је најчешће погрешан на терену, јер суфикс који телефон пријави на гостујућој мрежи није суфикс који сервира корпоративни resolver. Проверите име које уређај заиста разрешава пре него што се поуздате у правило.

Корак 3: тестирајте прелазе, а не статичну везу

Тунел који је активан док га гледате доказује врло мало. Изведите сваки прелаз намерно и забележите шта уређај ради, користећи исти приватни ресурс сваки пут да би резултати били упоредиви:

  • Повежите се на мрежу где би правило требало да се поклопи, затим затражите приватни ресурс и потврдите да се учитава.
  • Пређите на мобилну мрежу са апликацијом у позадини, затим је вратите у први план и поновите захтев.
  • Повежите се на Wi-Fi са captive порталом и видите да ли је портал доступан или принуда блокира све пре него што можете да се аутентификујете.
  • Ручно искључите тунел на надзираном уређају и проверите да ли се сам враћа и колико брзо.

Покрените исту листу на ненадзираном уређају ако га имате. Разлика између два резултата је стварно понашање примене и то је део који снимак екрана повезаног тунела никада не покаже.

Корак 4: познајте два облика квара

Принудна покривеност пада тако што блокира. Када тунел не може да се успостави, уређај губи обичан интернет приступ заједно са приватним ресурсима, а корисник доживљава телефон који је онлајн али не може да претражује. Поновно повезивање и блокирање су одвојена запажања, па забележите оба уместо да третирате нема интернета као један симптом.

On Demand пада тако што се не активира. Правило се не поклопи, тунел се не појави, а приватни ресурс једноставно истекне. Ово је лако погрешно дијагностиковати као проблем сервера, јер се клијент понаша тачно онако како је конфигурисан.

Captive портал стоји између два случаја: потребна му је повезаност пре него што тунел постоји, па политика која блокира све док тунел не буде активан треба документован пут кроз портал. То одлучите у дизајну, а не на help desk-у.

Корак 5: проверите, затим увежбајте враћање

Провера припада стварном путу са безопасним саобраћајем: затражите приватни ресурс који не сме бити јаван, потврдите коју адресу уређај представља споља и поновите након рестарта да бисте видели секвенцу покретања, а не само топло стање.

Затим вежбајте уклањање на тестном уређају пре него што вам икада затреба у продукцији. Уклањање профила враћа уређај у претходно стање, а знање колико то траје и шта корисник види део је упутства. Apple-ов водич за VPN безбедност је референца за оно што платформа документује о овим политикама и вреди га прочитати пре писања конфигурације која тврди више него што платформа тврди.

Држите три чињенице из првог корака уз скуп правила и резултате тестова. Када следећа особа пита зашто се телефон повезује на једној мрежи а не на другој, те белешке одговарају за минут уместо поновне изградње.

Повезани чланци