Зошто вашата iPhone апликација не може да го вклучи или исклучи системскиот VPN

Менаџер на производ бара копче што го вклучува корпоративниот VPN и барањето звучи тривијално. На iOS ова не е мала функција; таа стои надвор од јавниот договор и секое заобиколување или паѓа на прегледот или се крши во следното издание. Помини го барањето низ она што платформата навистина го дозволува и дизајнот главно сам се пишува. Апликацијата може да поседува VPN конфигурација и да ја стартува. Апликацијата не може да го достигне системскиот прекинувач, не може да ја прочита состојбата на профил што самата не го создала и не може да го држи корисникот поврзан против неговата волја.

Почнете од трите работи што корисникот ги мисли

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

Второто значење е она што ги создава прашањата на Stack Overflow и за него нема поддржан одговор. Прекинувачот во Поставки им припаѓа на корисникот, а на управувани уреди на профилот. Ниту едно јавно API не наведува VPN конфигурации, не известува дали системскиот тунел е активен ниту го префрла.

Што апликацијата навистина може да создаде

NetworkExtension и дава на апликацијата сопствена конфигурација преку NEVPNManager. Со правото Personal VPN и согласноста на корисникот, апликацијата зачувува конфигурација што се појавува во Поставки под нејзиното име и може да ја стартува или запре таа една врска. Тоа е вистинска способност што може да се прегледа, и тоа е воедно целиот опсег: менаџерот чита и пишува само она што сам го создал.

Правото не е автоматско. Го барате од Apple и образложувате зошто на апликацијата воопшто ѝ треба тунел, а клиент чија единствена цел е да го вклучи профилот на некој друг нема добар одговор. Давателите на пакетни тунели го следат истото правило со друга класа: NETunnelProviderManager поседува конфигурации засновани на давател што самата апликација ги инсталирала. Ниту еден од двата патишта не достигнува профил што го доставил MDM.

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

Читањето на состојбата удира во истиот ѕид

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

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

On Demand и Always On се вистинските лостови

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

Always On VPN е механизмот за наметнување и е врзан за надзор. На надгледуван уред MDM инсталира профил што го држи тунелот активен; на личен телефон без надзор истите клучеви не даваат исто однесување. Таа асиметрија е намерна и ниту една комбинација на клучеви на товарот не ја отстранува. Кога барањето навистина е VPN да биде вклучен, барањето всушност е уредот да биде управуван.

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

Испорачајте го поддржаниот пат

Четири прашања го решаваат механизмот пред да постои каков било код: чиј е уредот, дали е под надзор, кој клиент го завршува тунелот и од каде доаѓа профилот. Ако нешто од тоа е непознато, барањето за функција не е подготвено за проценка.

Приватно API што чепка во системскиот VPN ќе помине демо и ќе падне на прегледот, а ако се испорача на друг начин, ќе се скрши во следното издание на iOS. Нема верзија од таа размена што вреди за еден прекинувач.

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