Bakit hindi kayang buksan o patayin ng iyong iPhone app ang system VPN

Isang product manager ang humihingi ng buton na magbubukas ng VPN ng kumpanya, at mukhang walang kuwenta ang hiling. Sa iOS hindi ito maliit na tampok; nasa labas ito ng pampublikong kontrata, at bawat pag-iwas ay bumabagsak sa review o nasisira sa susunod na release. Dalhin ang hiling sa kung ano talaga ang pinapayagan ng platform, at karamihan ay kusang nagsusulat ang disenyo. Maaaring magmay-ari ang app ng configuration ng VPN at simulan ito. Ang app ay hindi kayang maabot ang system switch, hindi kayang basahin ang estado ng profile na hindi nito ginawa, at hindi kayang panatilihing konektado ang user laban sa kanyang kagustuhan.

Magsimula sa tatlong bagay na ibig sabihin ng user

Paghiwalayin ang mga kahulugan bago paghiwalayin ang mga API. May pagkakataong gusto ng user na konektado ang tunnel ng iyong app, may pagkakataong gusto niyang buksan ang switch sa Settings para sa profile na ininstalla ng iba, at may pagkakataong gusto niyang hindi makapag-browse ang telepono nang walang tunnel. Tumutugma ito sa tatlong magkaibang mekanismo, at tanging ang una ang bukas sa ordinaryong app.

Ang ikalawang kahulugan ang lumilikha ng mga tanong sa Stack Overflow, at wala itong sinusuportahang sagot. Ang switch sa Settings ay pag-aari ng user at, sa mga pinamamahalaang device, ng profile. Walang pampublikong API na naglilista ng mga configuration ng VPN, nag-uulat kung nakaangat ang system tunnel, o nagto-toggle nito.

Ano ang tunay na kayang likhain ng isang app

Binibigyan ng NetworkExtension ang app ng sarili nitong configuration sa pamamagitan ng NEVPNManager. Sa Personal VPN na karapatan at pahintulot ng user, sine-save ng app ang configuration na lumalabas sa Settings sa sarili nitong pangalan, at kaya nitong simulan o ihinto ang nag-iisang koneksyong iyon. Tunay at nasusuri itong kakayahan, at ito rin ang buong saklaw: binabasa at isinusulat lamang ng manager ang ginawa nito.

Ang karapatan ay hindi awtomatiko. Hinihiling mo ito sa Apple at ipinapaliwanag kung bakit kailangan ng app ng tunnel, at ang kliyenteng tanging layunin ay buksan ang profile ng iba ay walang magandang sagot. Sinusunod ng mga tagapagbigay ng packet tunnel ang parehong tuntunin sa ibang klase: pag-aari ng NETunnelProviderManager ang mga configuration na nakabatay sa provider na ininstalla ng app mismo. Wala sa dalawang landas ang umaabot sa profile na inihatid ng MDM.

Nalalapat din ang pahintulot sa oras ng pag-save. Ang pagsulat ng configuration ay nagtatanong sa user, at ang tanong na iyon ay hindi bagay na maaaring supilin ng app para sa kaginhawahan.

Ang pagbasa ng estado ay tumatama sa parehong pader

Mukhang mas palakaibigan ang estado kaysa kontrol at kasing-sarado. Iniulat ng NEVPNStatus ang di-wasto, nadiskonekta, kumokonekta, konektado, muling nagpapatibay o nadidiskonekta para sa sariling configuration ng app, at may notification sa bawat pagbabago. Wala itong sinasabi tungkol sa tunnel na ininstalla ng management profile, at iyon mismo ang estadong gustong makita ng help desk.

Ang pagmamanman ng network path at mga pagbabago sa interface ay iniaalok bilang kapalit sa mga review ng disenyo. Inilalarawan ng mga ito ang landas ng trapiko ng app, na nagbabago dahil sa mga dahilan na walang kaugnayan sa estado ng VPN, at ang paggamit sa mga ito bilang VPN reading ay nagbibigay ng interface na nagsisinungaling sa dalawang direksyon.

Ang On Demand at Always On ang tunay na levers

Nasa profile at hindi sa app nakatira ang mga sinusuportahang lever. Sinasabi ng mga patakaran ng On Demand sa system kung kailan kokonekta: isang nakaayos na listahan ng mga kundisyon na may mga aksyon, na sinusuri ng operating system, hindi ng iyong code. Ang patakaran na kumokonekta sa anumang interface ay lumilikha ng pakiramdam na laging konektado nang walang ibinibigay na kontrol sa anumang app.

Ang Always On VPN ang mekanismo ng pagpapatupad, at nakatali ito sa pangangasiwa. Sa sinusubaybayang device, nag-iinstall ang MDM ng profile na nagpapanatili sa tunnel, samantalang sa personal na teleponong hindi sinusubaybayan ay hindi nagbibigay ng parehong pag-uugali ang parehong mga key. Ang kawalan ng simetrya ay sinasadya, at walang kombinasyon ng payload key ang nag-aalis nito. Kapag ang kinakailangan ay talagang ang VPN ay dapat bukas, ang kinakailangan ay talagang ang device ay dapat pinamamahalaan.

Sa pagitan ng dalawa ay nakaupo ang mas mahinang pinsan: isang patakaran na muling kumokonekta matapos magdiskonekta ang user. Kumokonekta ito kapag susuriin ang patakaran sa susunod, na hindi katulad ng agaran, at mapapansin ng user na sadyang nagdiskonekta ang pagkakaiba. Idisenyo ang interface sa paligid ng puwang na iyon sa halip na mangako ng lock.

Ipadala ang sinusuportahang landas

Apat na tanong ang nagtatakda ng mekanismo bago pa may code: kanino ang device, sinusubaybayan ba ito, aling kliyente ang nagtatapos ng tunnel, at saan galing ang profile. Kung may hindi alam sa mga ito, hindi pa handa ang hiling ng tampok para sa pagtantya.

Ang pribadong API na humahawak sa system VPN ay papasa sa demo at babagsak sa review, at kung ipapadala sa ibang paraan ay masisira ito sa susunod na release ng iOS. Walang bersyon ng palitang iyon ang sulit para sa isang switch.

Ang telemetry ng pamamahala ay hiwalay na channel: iniuulat nito na may naka-install na profile at kung sumusunod ang device, na pag-uulat at hindi control surface bawat app. Subukan ang daloy sa tunay na device pagkatapos ng bawat update, dahil ang sinusuportahang pag-uugali ay nakatira sa OS at gumagalaw ang OS.