iOS-a VPN-profilo: passwordReference, ne la pasvorto

Vi instalas profilon, la tunelo ekfunkcias, kaj ĉio ŝajnas preta. Poste la telefono restartas, on-demand vekas la konekton sen programo en la malfono de la ekrano, kaj la tunelo rifuzas ekfunkcii. La profilo ankoraŭ estas tie kaj la pasvorto ankoraŭ ĝustas, kaj tial ĉi tiu paneo sendas homojn serĉi en la malĝusta loko. Network Extension ne povas legi vian sekreton el la profilo: ĝi bezonas ŝlosilringan referencon, kiun ĝi mem povas solvi.

La sekva trairo sekvas unu konekpropon tra tiu transdono, de la peto, kiu konstruas la referencon, ĝis la restartigo, kiu testas ĝin.

La profilo konservas tenilon, ne la sekreton

NEVPNProtocol malkaŝas passwordReference kaj sharedSecretReference pro kaŭzo. Kiam la demono lanĉas tunelon, ĝi eble ne funkcias ene de via procezo, do ĝi ne povas voki vian kodon kaj peti pasvorton. Ĝi legas daŭran ŝlosilringan referencon, solvas ĝin en sia propra kunteksto kaj mem venas la eron.

Vi konstruas tiun referencon demandante ĝin de la ŝlosilringo, kio estas malsama peto ol peti la datumojn:

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
]

Donu la redonitan objekton al la protokolo, ne la datumojn de la ero. Praktike la profilo registras, kie loĝas la sekreto, kaj tial sekurkopio de la agordo ne silente duobligas la pasvorton en plist-dosieron.

Kial la API respondas -50

errSecParam signifas, ke la peto aŭ la valoro estis misformitaj por la operacio, kaj ĝi estas la eraro plej ofte vidata, kiam la referencaj kaj datumaj petoj miksiĝas. Peti datumojn dum la riceva kodo atendas referencon, atribui krudajn bajtojn al passwordReference aŭ peti kun alirgrupo, kiun la programo ne povas uzi, ĉiuj produktas ĝin.

Volvaj bibliotekoj invitadas al tio. Helpaĵo, kiu redonas bajtojn, ne estas interŝanĝebla kun tiu, kiu redonas referencon, do la riparo estas kutime malsama peto anstataŭ malsama pasvorto.

La sama malkongruo klarigas profilon, kiu konserviĝas sen plendo kaj poste ne povas konekti: tio, kio konserviĝis, estas blob, ne tenilo, kaj la demono havas nenion por solvi.

Konserviĝas bone, malsukcesas ĉe konekto

Konservado ekzercas la kuntekston de via programo. Konektado ekzercas tiun de la demono, kaj la du ne havas la saman aliron. Profilo do povas trapasi ĉiun teston en la simulilo kaj malsukcesi ĉe la unua on-demand lanĉo.

Tia estas ankaŭ la formo de la simptomo de restartigo: ĝi funkcias dum la programo estas malfermita kaj mortas, kiam la sistemo mem lanĉas la tunelon.

Testu la fonan vojon intence antaŭ la livero. Ekigu on-demand-konekton kun la programo fermita, poste legu la konzolon de la aparato anstataŭ la protokolon de la programo, ĉar la paneon registras la procezo, kiu provis solvi la referencon. Se la konzolo montras, ke la demono rifuzas la eron, la referenco estas bona kaj la problemo estas la alirebleco de la ero.

Alirebleco decidas, ĉu restartigo funkcios

La ero devas esti legebla de kiu ajn sistema procezo, kiu lanĉas la tunelon, kaj tio estas pli larĝa publiko ol via programo, dum ĝi sidas en la unua plano. Tiu limigo elektas la alireblecan atributon por vi. Ero protektita ĝis la unua malŝloso estas disponebla por fona lanĉo post kiam la aparato estis malŝlosita unufoje; ero, kiu postulas, ke la aparato estu malŝlosita nun, ne estas.

Elekti la pli striktan klason estas tentanta kaj ĝuste tio rompas on-demand-profilon sur ŝlosita telefono.

Post ŝanĝi la klason, rekradu la eron anstataŭ redakti atributojn ĉe la ekzistanta, poste rekonservu la protokolon kun freŝa referenco. Atributaj ŝanĝoj ĉe ekzistanta ero ne ĉiam produktas la konduton, kiun la dokumentaro implicas, kaj rekonstruita ero forigas la dubon.

Rotacio estas kie putras la konservitaj profilaĵoj

Ŝanĝi la pasvorton en la ŝlosilringo ne aŭtomate ŝanĝas tion, al kio montras la konservita profilo. Forigi la eron estas pli malbone: la profilo tenas referencon al io, kio ne plu ekzistas, kaj la paneo aspektas kiel malakcepto de aŭtentigo.

Rotaciu en unu ordo. Ĝisdatigu la eron, petu novan daŭran referencon, rekonservu la protokolon, poste konektu kun la programo fermita por pruvi, ke la demono ankoraŭ povas solvi ĝin. Tenu la uzantpasvorton kaj la komunan sekreton en apartaj eroj, por ke ĉiu rotaciu laŭ sia propra horaro, kaj neniam registru la petan vortaron nek la referencon mem. La tenilo ne estas sekreto, sed ĝi estas mapo al unu.