iOS-VPN-profiili: passwordReference, ei salasana

Asennat profiilin, tunneli nousee ja kaikki näyttää valmiilta. Sitten puhelin käynnistyy uudelleen, on-demand herättää yhteyden ilman sovellusta etualalla, ja tunneli kieltäytyy käynnistymästä. Profiili on yhä paikallaan ja salasana yhä oikein, ja siksi tämä vika lähettää ihmiset etsimään väärästä paikasta. Network Extension ei voi lukea salaistasi profiilista: se tarvitsee avainnipun viitteen, jonka se voi itse ratkaista.

Alla oleva katsaus seuraa yhtä yhteysyritystä tuon luovutuksen läpi, viitteen rakentavasta kyselystä uudelleenkäynnistykseen, joka testaa sen.

Profiili tallentaa kahvan, ei salaisuutta

NEVPNProtocol paljastaa passwordReference- ja sharedSecretReference-kentät syystä. Kun daemon käynnistää tunnelin, se ei välttämättä toimi prosessissasi, joten se ei voi kutsua koodiasi ja pyytää salasanaa. Se lukee pysyvän avainnipun viitteen, ratkaisee sen omassa kontekstissaan ja hakee kohteen itse.

Rakennat tuon viitteen kysymällä sitä avainnipulta, mikä on eri pyyntö kuin datan pyytäminen:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

Anna palautettu objekti protokollalle, älä kohteen dataa. Käytännössä profiili kirjaa, missä salaisuus asuu, ja siksi kokoonpanon varmuuskopio ei kopioi salasanaa hiljaa plistiin.

Miksi API vastaa -50

errSecParam tarkoittaa, että pyyntö tai arvo oli väärin muodostettu toimintoa varten, ja se on virhe, joka nähdään useimmin, kun viite- ja datapyynnöt menevät sekaisin. Datan pyytäminen, kun vastaanottava koodi odottaa viitettä, raakojen tavujen antaminen passwordReference-kentälle tai kysely käyttöryhmällä, jota sovellus ei voi käyttää, kaikki tuottavat sen.

Kääreluokat kutsuvat siihen. Tavuja palauttava apuri ei ole vaihdettavissa sellaiseen, joka palauttaa viitteen, joten korjaus on yleensä eri kysely eikä eri salasana.

Sama ristiriita selittää profiilin, joka tallentuu valittamatta ja sitten ei yhdistä: tallennettu on blob, ei kahva, eikä daemonilla ole mitään ratkaistavaa.

Tallentuu hyvin, epäonnistuu yhdistettäessä

Tallentaminen harjoittaa sovelluksesi kontekstia. Yhdistäminen harjoittaa daemonin kontekstia, eikä kahdella ole samaa pääsyä. Siksi profiili voi läpäistä kaikki simulaattorissa tehdyt testit ja epäonnistua ensimmäisellä on-demand-käynnistyksellä.

Sama muoto on uudelleenkäynnistyksen oireessa: se toimii, kun sovellus on auki, ja kuolee, kun järjestelmä käynnistää tunnelin itse.

Testaa taustapolku tarkoituksella ennen julkaisua. Käynnistä on-demand-yhteys sovelluksen ollessa kiinni ja lue sitten laitteen konsolia älä sovelluksen lokia, koska vian kirjaa prosessi, joka yritti ratkaista viitteen. Jos konsoli näyttää, että daemon hylkää kohteen, viite on kunnossa ja ongelma on kohteen saavutettavuus.

Saavutettavuus ratkaisee, toimiiko uudelleenkäynnistys

Kohteen on oltava luettavissa mille tahansa järjestelmäprosessille, joka käynnistää tunnelin, ja se on laajempi yleisö kuin sovelluksesi etualalla. Tämä rajoitus valitsee saavutettavuusmääritteen puolestasi. Kohde, joka on suojattu ensimmäiseen avaamiseen asti, on taustakäynnistyksen käytettävissä, kun laite on avattu kerran; kohde, joka vaatii laitteen avaamista juuri nyt, ei ole.

Tiukemman luokan valitseminen on houkuttelevaa, ja juuri se rikkoo on-demand-profiilin lukitussa puhelimessa.

Kun olet vaihtanut luokan, luo kohde uudelleen sen sijaan että muokkaisit olemassa olevan määritteitä, ja tallenna protokolla sitten uudelleen tuoreella viitteellä. Määritemuutokset olemassa olevaan kohteeseen eivät aina tuota dokumentaation vihjaamaa käytöstä, ja uudelleen rakennettu kohde poistaa epäilyksen.

Kierrätys on paikka, jossa tallennetut profiilit mätänevät

Salasanan vaihtaminen avainnipussa ei automaattisesti muuta sitä, mihin tallennettu profiili osoittaa. Kohteen poistaminen on pahempaa: profiili pitää viitteen johonkin, jota ei enää ole, ja vika näyttää todennuksen hylkäykseltä.

Kierrätä yhdessä järjestyksessä. Päivitä kohde, kysy uusi pysyvä viite, tallenna protokolla uudelleen ja yhdistä sitten sovelluksen ollessa kiinni todistaaksesi, että daemon voi yhä ratkaista sen. Pidä käyttäjän salasana ja jaettu salaisuus erillisissä kohteissa, jotta kumpikin kierrä oman aikataulunsa mukaan, äläkä koskaan kirjaa kyselyn sanakirjaa tai viitettä itseään. Kahva ei ole salaisuus, mutta se on kartta sellaiseen.