iOS-VPN-profiel: passwordReference, nie die wagwoord nie

Jy installeer ’n profiel, die tonnel kom op, en alles lyk klaar. Dan herbegin die foon, on-demand wek die verbinding met geen program in die voorgrond nie, en die tonnel weier om te begin. Die profiel is steeds daar en die wagwoord is steeds korrek, en daarom laat hierdie fout mense op die verkeerde plek soek. ’n Network Extension kan nie jou geheim uit die profiel lees nie: dit het ’n sleutelringverwysing nodig wat dit self kan oplos.

Die deurloop hieronder volg een verbindingspoging deur daardie oorhandiging, van die navraag wat die verwysing bou tot die herbegin wat dit toets.

Die profiel stoor ’n handvatsel, nie die geheim nie

NEVPNProtocol stel passwordReference en sharedSecretReference om ’n rede bloot. Wanneer die daemon ’n tonnel begin, hardloop dit dalk nie in jou proses nie, so dit kan nie jou kode roep en om ’n wagwoord vra nie. Dit lees ’n blywende sleutelringverwysing, los dit in sy eie konteks op, en haal die item self.

Jy bou daardie verwysing deur die sleutelring daarvoor te vra, wat ’n ander navraag is as om die data te vra:

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
]

Gee die teruggekeerde voorwerp aan die protokol, nie die item se data nie. In die praktyk teken die profiel aan waar die geheim woon, en daarom dupliseer ’n konfigurasierugsteun nie die wagwoord stilletjies in ’n plist nie.

Waarom die API -50 antwoord

errSecParam beteken die navraag of die waarde was wanvormig vir die bewerking, en dit is die fout wat die meeste gesien word wanneer die verwysing- en datanavrae deurmekaar raak. Om data te vra terwyl die ontvangende kode ’n verwysing verwag, om rou grepe aan passwordReference toe te wys, of om te vra met ’n toegangsgroep wat die program nie kan gebruik nie, lewer dit almal.

Omhulselbiblioteke nooi dit uit. ’n Helper wat grepe teruggee, is nie uitruilbaar met een wat ’n verwysing teruggee nie, so die herstel is gewoonlik ’n ander navraag eerder as ’n ander wagwoord.

Dieselfde wanaanpassing verduidelik ’n profiel wat sonder klag stoor en dan nie kan koppel nie: wat gestoor is, is ’n blob, nie ’n handvatsel nie, en die daemon het niks om op te los nie.

Stoor fyn, faal by verbindingstyd

Stoor beoefen jou program se konteks. Koppel beoefen die daemon s’n, en die twee het nie dieselfde toegang nie. ’n Profiel kan dus elke toets in die simulator slaag en by die eerste on-demand begin faal.

Dit is ook die vorm van die herbegin-simptoom: dit werk terwyl die program oop is en sterf wanneer die stelsel die tonnel self begin.

Toets die agtergrondpad doelbewus voor versending. Veroorsaak ’n on-demand verbinding met die program toe, en lees dan die toestelkonsole eerder as die programlog, want die fout word deur die proses aangeteken wat probeer het om die verwysing op te los. As die konsole wys die daemon verwerp die item, is die verwysing fyn en is die item se toeganklikheid die probleem.

Toeganklikheid bepaal of ’n herbegin werk

Die item moet leesbaar wees vir watter stelselproses ook al die tonnel begin, en dit is ’n wyer gehoor as jou program terwyl dit in die voorgrond sit. Daardie beperking kies die toeganklikheidskenmerk vir jou. ’n Item wat beskerm is tot eerste ontsluiting is beskikbaar vir ’n agtergrondbegin nadat die toestel een keer ontsluit is; ’n item wat vereis dat die toestel nou ontsluit is, is nie.

Om die strenger klas te kies is aanloklik en dit is juis wat ’n on-demand profiel op ’n geslote foon breek.

Nadat jy die klas verander het, skep die item oor eerder as om kenmerke op die bestaande een te wysig, en stoor dan die protokol weer met ’n vars verwysing. Kenmerkveranderinge op ’n bestaande item lewer nie altyd die gedrag wat die dokumentasie impliseer nie, en ’n herboude item verwyder die twyfel.

Rotasie is waar gestoorde profiele verrot

Om die wagwoord in die sleutelring te verander, verander nie outomaties waarheen die gestoorde profiel wys nie. Om die item te verwyder is erger: die profiel hou ’n verwysing na iets wat nie meer bestaan nie, en die fout lyk soos ’n verwerping van verifikasie.

Roteer in een volgorde. Werk die item by, vra ’n nuwe blywende verwysing, stoor die protokol weer, en koppel dan met die program toe om te bewys die daemon kan dit steeds oplos. Hou die gebruiker se wagwoord en die gedeelde geheim in aparte items sodat elkeen op sy eie skedule roteer, en teken nooit die navraagwoordeboek of die verwysing self aan nie. Die handvatsel is nie ’n geheim nie, maar dit is ’n kaart na een.