Miksi iOS VPN -sovelluksesi näyttää yhteyden katkenneen, vaikka tunneli on pystyssä

Sovelluksesi sanoo katkennut, valikkopalkki sanoo yhdistetty, ja liikenne selvästi virtaa. Tämä ero ei ole kilpatilanne, jonka korjaat uusintayrityksellä: sovellus ja tunneli ovat erillisiä prosesseja, ja objekti, jota koodisi lukee, on välimuistissa oleva näkymä järjestelmän tallentamasta kokoonpanosta. Applen Personal VPN -pinta on hallinta-API, ei datapolku, ja suurin osa sen omituisesta käytöksestä seuraa tästä yhdestä tosiasiasta. Tässä on, mitä jokaisessa kutsussa todella tapahtuu.

Hallintaobjekti on välimuistissa oleva näkymä, ei tunneli

NETunnelProviderManager täytetään asetussäilöstä, jonka omistaa järjestelmä, joten sen ominaisuudet eivät merkitse mitään ennen kuin loadFromPreferences on valmis. Jos luet connection.status ennen sitä, saat oletusarvon, ja siksi ensimmäinen tilapäivitys uudelleenkäynnistyksen jälkeen ilmoittaa katkenneen, vaikka tunneli on pystyssä. Lataa ensin ja lue sitten tila ja protokollan kokoonpano samasta valmistumiskäsittelijästä. Seuraa myöhempiä muutoksia NEVPNStatusDidChange kautta sen sijaan että kyselisit, ja huomaa, että ilmoitus laukeaa myös On Demandin käynnistämille yhteyksille, joissa ei ole lainkaan sovelluskutsua, joka voisi palauttaa jotain. Sama koskee protokolla-asetuksia: ne luetaan ladatusta kokoonpanosta, ei siitä, mitä sovellus välitti.

Tunneli itse elää Network Extension -tarjoajan prosessissa, joten sovellus voi menettää oman tilansa menettämättä yhteyttä. Kaikki, mitä käyttöliittymä näyttää, on rakennettava uudelleen hallinnasta, ei muistettava edellisestä istunnosta.

Käynnistysjärjestys: tallenna, lataa ja käynnistä sitten

Tarjoajapohjainen yhteys tarvitsee kolme vaihetta järjestyksessä. Kirjoita tarjoajan kokoonpano ja kutsu saveToPreferences, lataa hallinta niin että tallennettu kokoonpano on se, joka sinulla on, ja käynnistä sitten NETunnelProviderSession.startVPNTunnel() kautta. Jos ohitat tallennuksen, käynnistyksellä ei ole mitään käynnistettävää; jos lataat ennen tallennusta, hallinta heijastaa yhä vanhaa kokoonpanoa.

startVPNTunnel:n palauttama totuusarvo kertoo vain, että pyyntö hyväksyttiin. Tarjoajatason virheet saapuvat myöhemmin tilamuutoksena katkenneeksi, jonka havaitset ilmoituksesta NEVPNStatusDidChange, ja ilmoituksen käsittelijän on luettava connection.status uudelleen loadFromPreferences:n jälkeen, koska välimuistissa oleva arvo voi olla yhä vanha. Pyyntötason virheet palaavat heti kutsun poikkeuksen heittävästä muodosta tai startVPNTunnelAndReturnError::n virhetulosteparametrin kautta. Koodi, joka pitää paluuarvoa tuloksena, raportoi yhteyden, jota ei koskaan muodostettu. Toinen hiljainen epäonnistuminen on tarjoajan nipun tunniste, joka ei vastaa asennettua laajennusta: pyyntö hylätään, eikä mikään viestissä viittaa tunnisteeseen. Jos tunniste on väärä, pyyntö yleensä epäonnistuu heti, ennen kuin yhtään tarjoajan lokiriviä ilmestyy.

Asetusten uudelleenlataus käynnistyksen jälkeen on se, mikä tekee tilanäkymistä oikeita. Hallinta ei työnnä sinulle uutta kokoonpanoa, kun järjestelmä muuttaa sitä.

Luottamusaineisto saapuu profiilin kautta, ei koskaan sovelluskoodista

Sovelluksella ei ole tuettua tapaa lisätä juurivarmentetta iOS:n luottamussäilöön, joten Personal VPN -kokoonpano voi viitata vain aineistoon, johon laite jo luottaa: ketju, jonka on luonut asennettu profiili, laitehallinta tai CA, johon järjestelmä luottaa muista syistä. Sovellus, joka luo oman CA:nsa ensimmäisellä käynnistyksellä ja odottaa järjestelmän hyväksyvän sen, epäonnistuu validoinnissa tarjoajan sisällä, missä sovelluksen käyttöliittymä ei näe syytä.

Kohtele tätä rajaa sellaisena suunnittelurajoituksena kuin se on ja toimita luottamusankkuri rekisteröintiprofiilin mukana. Pidä VPN-todennus erillään luottamuspäätöksestä, koska ne epäonnistuvat eri paikoissa ja eri ihmiset debuggaavat niitä.

Laskurit tulevat liitännästä, eivät VPN-API:sta

Hallinta paljastaa tilan ja kokoonpanon, eikä mitään, mikä laskisi tavuja tunnelia kohden. Jos tarvitset käyttölukuja, kutsu getifaddrs() ja lue if_data kyseiselle liitännälle: en0 Wi-Fiä varten, pdp_ip-liitännät matkapuhelinverkolle ja utun-laite itse tunnelille. utun-laskurit kuvaavat sisäistä liikennettä ja sisältävät protokollan ylimenon.

Nämä luvut ovat arvioita, eivät sovelluskohtaista kirjanpitoa, ja ne nollautuvat, kun liitäntä luodaan uudelleen. Merkitse ne käyttöliittymässä niin, tai joku käyttää niitä asiakkaan laskuttamiseen. Jos tarvitset sovelluskohtaisia lukuja, tarvitset täysin toisen mekanismin, et parempaa näiden kenttien lukemista.

Siivous kuuluu stopVPNTunneliin, ei lopetukseen

applicationWillTerminate antaa sinulle muutaman sekunnin ennen kuin järjestelmä voi tappaa prosessin, mikä ei ole luotettava paikka purkaa yhteys. Lähetä pysäytys stopVPNTunnel():lle tai käsittele se tarjoajan pysäytyscallbackissa, ja säilytä hallinnan tai kokoonpanon tunniste, jolla aloitit, jotta pysäytys osuu juuri siihen yhteyteen eikä jokaiseen laitteen kokoonpanoon.

Tallenna tämä tunniste sen profiilin viereen, johon se kuuluu, koska hallintaobjekti ei kirjaa, minkä kokoonpanon käyttäjä valitsi. Ja muista, että On Demandin nostamalla yhteydellä ei ole lainkaan sovelluskutsua takanaan, joten tilanäkymän on silti ladattava asetukset ennen kuin se piirtää mitään.