iOS VPN профил: passwordReference, а не лозинката

Референцата во приврзокот за клучеви е рачка, а не тајната. Преносот на бајти ја објаснува грешката -50, неуспехот при рестартирање и стапицата со ротација во зачуваните VPN профили.

Инсталирате профил, тунелот се подига и изгледа завршено. Потоа телефонот се рестартира, on-demand ја буди врската без апликација во преден план, и тунелот одбива да стартува. Профилот останува таму и лозинката останува точна, затоа овој дефект ги праќа луѓето да бараат на погрешно место. Network Extension не може да ја прочита тајната од профилот: му треба референца во приврзокот за клучеви што може сам да ја реши.

Прегледот подолу следи еден обид за поврзување низ тоа предавање, од барањето што ја гради референцата до рестартирањето што ја проверува.

Профилот чува рачка, а не тајната

NEVPNProtocol ги изложува passwordReference и sharedSecretReference со причина. Кога демонот стартува тунел, тој можеби не работи во вашиот процес, па не може да го повика вашиот код и да побара лозинка. Тој чита постојана референца во приврзокот за клучеви, ја решава во сопствениот контекст и сам го зема елементот.

Ја градите таа референца со тоа што ќе ја побарате од приврзокот за клучеви, што е различно барање од барањето за податоците:

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
]

Предајте го вратениот објект на протоколот, а не податоците од елементот. Во пракса профилот запишува каде живее тајната, затоа и резервната копија на конфигурацијата не ја дуплира лозинката тивко во plist.

Зошто API одговара со -50

errSecParam значи дека барањето или вредноста биле погрешно обликувани за операцијата, и тоа е грешката што најчесто се гледа кога барањата за референца и за податоци се мешаат. Барање податоци додека кодот што прима очекува референца, доделување сурови бајти на passwordReference или барање со група за пристап што апликацијата не може да ја користи, сите ја создаваат.

Библиотеките-обвивки го поттикнуваат ова. Помошник што враќа бајти не е заменлив со оној што враќа референца, па поправката обично е друго барање, а не друга лозинка.

Истото несовпаѓање објаснува профил што се зачувува без поплака и потоа не се поврзува: зачуваното е blob, а не рачка, и демонот нема што да реши.

Се зачувува добро, паѓа при поврзување

Зачувувањето го вежба контекстот на вашата апликација. Поврзувањето го вежба тој на демонот, и двете немаат ист пристап. Затоа профилот може да ги помине сите тестови во симулаторот и да падне при првиот on-demand старт.

Таков е и обликот на симптомот при рестартирање: работи додека апликацијата е отворена и умира кога системот сам го стартува тунелот.

Тестирајте ја позадинската патека намерно пред испорака. Предизвикајте on-demand врска со затворена апликација, потоа читајте ја конзолата на уредот, а не дневникот на апликацијата, зашто дефектот го запишува процесот што се обидел да ја реши референцата. Ако конзолата покажува дека демонот го одбива елементот, референцата е во ред и проблемот е достапноста на елементот.

Достапноста одлучува дали рестартирањето ќе работи

Елементот мора да биде читлив за кој било системски процес што го стартува тунелот, а тоа е поширока публика од вашата апликација во преден план. Тоа ограничување го избира атрибутот за достапност наместо вас. Елемент заштитен до првото отклучување е достапен за позадински старт откако уредот еднаш е отклучен; елемент што бара уредот да биде отклучен токму сега не е.

Изборот на построгата класа е примамлив и токму тоа го крши on-demand профилот на заклучен телефон.

По промената на класата пресоздајте го елементот наместо да уредувате атрибути на постојниот, па повторно зачувајте го протоколот со свежа референца. Промените на атрибути на постоен елемент не секогаш го даваат однесувањето што документацијата го подразбира, а пресоздадениот елемент ја отстранува сомнежот.

Ротацијата е местото каде зачуваните профили гнијат

Промената на лозинката во приврзокот за клучеви не менува автоматски тоа на што покажува зачуваниот профил. Бришењето на елементот е полошо: профилот држи референца на нешто што повеќе не постои, а дефектот изгледа како одбиена автентикација.

Ротирајте по еден редослед. Ажурирајте го елементот, побарајте нова постојана референца, зачувајте го протоколот повторно, па поврзете се со затворена апликација за да докажете дека демонот уште може да ја реши. Држете ја корисничката лозинка и заедничката тајна во одделни елементи за секоја да се ротира по свој распоред, и никогаш не логирајте го речникот на барањето ниту самата референца. Рачката не е тајна, но е карта до неа.

Поврзани статии