Miksi iPhone-sovelluksesi ei voi kytkeä järjestelmän VPN:ää päälle tai pois

Tuotepäällikkö pyytää painiketta, joka kytkee yrityksen VPN:n päälle, ja pyyntö kuulostaa triviaalilta. iOS:ssä se ei ole pieni ominaisuus; se seisoo julkisen sopimuksen ulkopuolella, ja jokainen kiertotie joko epäonnistuu katselmoinnissa tai hajoaa seuraavassa julkaisussa. Käy pyyntö läpi sen kanssa, mitä alusta todella sallii, ja suunnittelu kirjoittaa itsensä pitkälti itse. Sovellus voi omistaa VPN-konfiguraation ja käynnistää sen. Sovellus ei yllä järjestelmän kytkimeen, ei voi lukea profiilin tilaa, jota se ei itse luonut, eikä pitää käyttäjää yhdistettynä tämän tahdon vastaisesti.

Aloita kolmesta asiasta, joita käyttäjä tarkoittaa

Erottele merkitykset ennen kuin erottelet API:t. Joskus käyttäjä haluaa sovelluksesi tunnelin olevan yhdistetty, joskus hän haluaa Asetusten kytkimen päälle toisen asentamalle profiilille, ja joskus hän haluaa, ettei puhelimella voi selata ilman tunnelia. Nämä vastaavat kolmea eri mekanismia, ja vain ensimmäinen on avoin tavalliselle sovellukselle.

Toinen merkitys on se, joka synnyttää Stack Overflow -kysymykset, eikä siihen ole tuettua vastausta. Asetusten kytkin kuuluu käyttäjälle ja hallituilla laitteilla profiilille. Mikään julkinen API ei luettele VPN-konfiguraatioita, raportoi, onko järjestelmän tunneli ylhäällä, eikä kytke sitä.

Mitä sovellus voi todella luoda

NetworkExtension antaa sovellukselle oman konfiguraation NEVPNManager:n kautta. Personal VPN -oikeudella ja käyttäjän suostumuksella sovellus tallentaa konfiguraation, joka näkyy Asetuksissa sen omalla nimellä, ja se voi käynnistää tai pysäyttää juuri tuon yhteyden. Se on todellinen, katselmoitava kyvykkyys, ja se on myös koko laajuus: hallinta lukee ja kirjoittaa vain sen, mitä se itse loi.

Oikeus ei ole automaattinen. Pyydät sitä Applelta ja perustelet, miksi sovellus ylipäätään tarvitsee tunnelin, eikä asiakkaalla, jonka ainoa tavoite on kytkeä jonkun toisen profiili päälle, ole hyvää vastausta. Pakettitunnelien tarjoajat noudattavat samaa sääntöä eri luokalla: NETunnelProviderManager omistaa tarjoajapohjaiset konfiguraatiot, jotka sovellus itse asensi. Kumpikaan polku ei yllä profiiliin, jonka MDM toimitti.

Suostumus pätee myös tallennushetkellä. Konfiguraation kirjoittaminen kysyy käyttäjältä, eikä sitä kysymystä sovellus saa vaientaa mukavuuden vuoksi.

Tilan lukeminen törmää samaan seinään

Tila näyttää ystävällisemmältä kuin hallinta ja on yhtä suljettu. NEVPNStatus raportoi sovelluksen oman konfiguraation kohdalla virheellinen, katkaistu, yhdistää, yhdistetty, vahvistaa uudelleen tai katkaisee, ja jokaisesta muutoksesta laukeaa ilmoitus. Se ei kerro mitään hallintaprofiilin asentamasta tunnelista, ja juuri sitä tilaa tukipalvelu haluaa nähdä.

Verkkopolun seurantaa ja liitännän muutoksia tarjotaan korvikkeina suunnittelukatselmoinneissa. Ne kuvaavat polun, jonka sovelluksen liikenne kulkee, ja se muuttuu syistä, jotka eivät liity VPN:n tilaan, ja niiden käyttäminen VPN-lukemana antaa käyttöliittymän, joka valehtelee molempiin suuntiin.

On Demand ja Always On ovat todelliset vivut

Tuetut vivut elävät profiilissa, eivät sovelluksessa. On Demand -säännöt kertovat järjestelmälle, milloin yhdistää: järjestetty luettelo ehdoista ja toiminnoista, jonka arvioi käyttöjärjestelmä, ei sinun koodisi. Sääntö, joka yhdistää millä tahansa liitännällä, luo aina-yhdistetty-tunteen antamatta sovellukselle mitään hallintaa.

Always On VPN on pakotusmekanismi, ja se on sidottu valvontaan. Valvotulla laitteella MDM asentaa profiilin, joka pitää tunnelin ylhäällä; valvomattomassa henkilökohtaisessa puhelimessa samat avaimet eivät tuota samaa käyttäytymistä. Tämä epäsymmetria on tahallinen, eikä mikään hyötykuorman avainten yhdistelmä poista sitä. Kun vaatimus on todella se, että VPN:n on oltava päällä, vaatimus on oikeastaan se, että laitetta on hallittava.

Niiden välissä istuu heikompi serkku: sääntö, joka yhdistää uudelleen sen jälkeen, kun käyttäjä katkaisi. Se yhdistää, kun sääntö arvioidaan seuraavan kerran, mikä ei ole sama kuin heti, ja tarkoituksella katkaissut käyttäjä huomaa eron. Suunnittele käyttöliittymä tämän aukon ympärille sen sijaan, että lupaisit lukon.

Toimita tuettu polku

Neljä kysymystä ratkaisevat mekanismin ennen kuin koodia on: kuka omistaa laitteen, onko se valvottu, mikä asiakas päättää tunnelin ja mistä profiili tulee. Jos jokin näistä on tuntematon, ominaisuustoive ei ole valmis arvioitavaksi.

Yksityinen API, joka sorkkii järjestelmän VPN:ää, läpäisee demon ja epäonnistuu katselmoinnissa, ja jos se toimitetaan muuta kautta, se hajoaa seuraavassa iOS-julkaisussa. Tuolle vaihdolle ei ole versiota, joka olisi kytkimen arvoinen.

Hallinnan telemetria on erillinen kanava: se raportoi, että profiili on asennettu ja onko laite vaatimusten mukainen, mikä on raportointia eikä sovelluskohtaista hallintapintaa. Testaa kulku oikealla laitteella jokaisen päivityksen jälkeen, koska tuettu käyttäytyminen elää käyttöjärjestelmässä ja käyttöjärjestelmä liikkuu.