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 суфиксот е условот што најчесто е погрешен на терен, бидејќи суфиксот што телефон го пријавува на гостинска мрежа не е оној што го служи корпоративниот резолвер. Проверете го името што уредот навистина го решава пред да му верувате на правилото.

Чекор 3: тестирајте ги премините, а не статичната врска

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

  • Поврзете се на мрежа каде правилото треба да се совпадне, па побарајте го приватниот ресурс и потврдете дека се вчитува.
  • Префрлете се на мобилна мрежа со апликацијата во позадина, па вратете ја напред и повторете го барањето.
  • Поврзете се на Wi-Fi со captive portal и видете дали порталот е достапен или наметнувањето го блокира пред автентикација.
  • Исклучете го тунелот рачно на надгледуван уред и проверете дали се враќа сам и колку брзо.

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

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

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

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

Captive portal стои меѓу двете: му треба поврзаност пред тунелот да постои, затоа политика што блокира сè додека тунелот не се подигне бара документирана патека низ порталот. Одлучете го тоа во дизајнот, не на сервисната маса.

Чекор 5: проверете, па вежбајте го враќањето

Проверката припаѓа на вистинската патека со безопасен сообраќај: побарајте приватен ресурс што не смее да биде јавен, потврдете која адреса уредот ја прикажува кон надвор и повторете по рестартирање за да ја видите низата на подигање, а не само топлата состојба.

Потоа вежбајте го отстранувањето на тест уред пред да ви треба во продукција. Отстранувањето на профилот го враќа уредот во претходната состојба, а знаењето колку трае и што гледа корисникот е дел од runbook. Appleовиот водич за безбедност на VPN е референцата за она што платформата го документира за овие политики и вреди да се прочита пред да напишете конфигурација што тврди повеќе од платформата.

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

Поврзани статии