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 е източникът какво платформата документира за тези политики и си струва да се прочете, преди да пишете конфигурация, която твърди повече от платформата.

Дръжте трите факта от първата стъпка до набора от правила и резултатите. Когато следващият човек попита защо телефон се свързва в една мрежа, а в друга не, тези бележки отговарят за минута вместо преправяне.

Подобни статии