Mitä NEVPNManager voi luoda iOSissa (ja mitä ei)

Kun rakennat VPN-näkymän iOS-sovelluksen sisään, ensimmäinen yllätys on, että Asetukset-sovelluksen protokollaluettelo ei ole rajapinnan luettelo. Network Extension -kehys antaa sovelluksesi luoda yhden henkilökohtaisen VPN-kokoonpanon, joka on kyseisen sovelluksen omistama, ja se hyväksyy vain muutaman protokollaobjektin. Kaikki muu, mitä ihmiset odottavat, L2TP:stä ladattuun profiiliin, on tämän pinnan ulkopuolella tai Applen yksityistä. Seuraavat epäonnistumiset eivät yleensä ole virheitä, ne ovat rajapinnan kieltäytyminen työstä, jota sille ei koskaan annettu.

Myytti: rajapinta on Asetusten muokkain

Uskotaan, että koska iOS voi määrittää IKEv1-, IKEv2-, L2TP- ja IPsec-profiileja, sovellus voi luoda minkä tahansa niistä ohjelmallisesti. Ei voi. Kehys tarjoaa kutsujalle täsmälleen yhden kokoonpanopaikan, ja se paikka hyväksyy pienen joukon julkisia protokollaluokkia. Kaikki muu, mitä ihmiset odottavat, L2TP:stä ladattuun profiiliin, on tämän pinnan ulkopuolella tai Applen yksityistä.

Seuraavat epäonnistumiset eivät yleensä ole virheitä. Ne ovat rajapinnan kieltäytyminen työstä, jota sille ei koskaan annettu, ja korjaus on suunnitella näkymä sen ympärille, mitä rajapinta omistaa.

Kolme protokollaobjektia ja ne, joita ei ole olemassa

Vaihtoehtosi ovat IKEv1 NEVPNProtocolIPSec kautta, IKEv2 NEVPNProtocolIKEv2 kautta ja NETunnelProviderProtocol, jos toimitat oman pakettitunnelilaajennuksesi. NEVPNManager-viite luettelee hyväksytyt protokollaobjektit. L2TP ja PPTP eivät koskaan esiinny siinä luettelossa, koska Apple ei julkaissut niille luokkia. Kummankin yrittäminen päättyy tallennushetkellä virheeseen tai pahempaan: kokoonpanoon, jota järjestelmä hiljaa kieltäytyy käyttämästä.

Työpöytäkoodi noudattaa eri sääntöjä. macOSissa SCNetworkInterfaceCreateWithInterface pinouttaa liitäntätyypin, kuten L2TP IPv4:n päällä, ja liittää sen verkkopalveluun, ja networksetup -connectpppoeservice käynnistää tuloksen. Järjestelmänvalvojan oikeudet ja aputyökalu tarvitaan, koska jaettu salaisuus ja salasana menevät järjestelmän avainnippuun. Kopioi tämä suunnittelu iOSiin, niin mikään ei käänny.

Anna avainnipun viittaus, älä salasanaa

Kumpikaan IKE-luokka ei hyväksy salasanaa tekstinä. Kaksi ominaisuutta passwordReference ja sharedSecretReference haluavat pysyvän avainnipun viittauksen, jonka saat funktiosta SecItemCopyMatching pyytämällä kSecReturnPersistentRef. Kohteen tietojen välittäminen tai merkkijonon työntäminen kenttään tuottaa tallennusvirheen tai yhteyden, jossa on tyhjät tunnistetiedot. Viittaus on vain niin kestävä kuin sen takana oleva avainnipun kohde, minkä vuoksi kohteen on oltava olemassa ennen kokoonpanon kokoamista. Luo se samassa tapahtumassa tallennuksen kanssa, niin poistat kokonaisen luokan järjestysvirheitä.

Varmennevarmennus kulkee toista reittiä: identityData plus identityDataPassword PKCS#12-blobille. Sen blobin toimittaminen sovelluksen nipussa on esimerkkikoodista periytynyt tapa, ei julkaisupäätös, koska salasana kulkee sen mukana ja jokainen sovelluksen kopio kantaa saman identiteetin.

Oikeutus ja saatavuus portittavat kaiken

Hallintaobjektia ei ehkä ole ollenkaan, ja syy on provisiointi. Sovelluksesi tunnisteen tarvitsee Network Extension -ominaisuuden sekä henkilökohtaisen VPN:n oikeutuksen, ja buildin allekirjoittavassa profiilissa on oltava molemmat.

Jätä se väliin, niin jaettu instanssi palauttaa nil tai tallennus epäonnistuu virheellä, joka ei koskaan mainitse oikeutusta. Saatavuus on toinen portti. Jos kohdistat vanhempaan kuin iOS 8, symboli puuttuu suorituksen aikana, joten epäonnistuminen on kaatuminen tai nil-hallintaobjekti, ei hallintaobjekti ilman kokoonpanoa. Tarkista suoritusympäristö ja oikeutus ennen objektikaaviosi virheenkorjausta.

Lataa, muokkaa, tallenna ja seuraa sitten tarvittaessa tilausta

Käsittele elinkaarta latauksena, muutoksena ja tallennuksena äläkä koskaan ohita latausta. Ennen kuin loadFromPreferences on valmis, hallintaobjekti ei pidä mitään eikä protokollaobjektia voi lukea tai vaihtaa.

Toinen tallennus korvaa kokoonpanon sen sijaan, että lisäisi toisen, joten kesken jäänyt tallennus voi vahingoittaa profiilia, joka toimi. Tarvittaessa-säännöt muodostavat järjestetyn taulukon, ja se järjestys on käytäntö. Laita mistä tahansa yhdistämisen sääntö irrotussäännön edelle, niin manuaalisen irrotuksen jälkeen seuraa välitön uudelleenyhdistäminen, mikä näyttää vialta mutta noudattaa dokumentoitua arviointia.

Siirrä irrotussääntö etualalle, kun käyttäjän toiminnon on voitettava. Se, mikä jää sovelluksen hallinnan ulkopuolelle, on yhtä tärkeää. Reitit tulevat tunnelista tai palvelimen käytännöstä, eivät asetuksesta, jonka sinä asetat, ja pakettitunnelipalvelun tarjoaja raportoi ne käynnistyessään. Sovellus ei voi luetella tai muokata muiden sovellusten tai kokoonpanoprofiilien asentamia profiileja, joten älä lupaa näkymää, joka näyttää laitteen jokaisen VPN:n.