Hindi wasto ang status ng NEVPNManager hanggang ma-load ang mga kagustuhan

I-restart ang app, tanungin ang manager tungkol sa status ng koneksyon, at iniuulat nitong di-konektado habang malinaw na nagpapakita ang menu ng system ng buhay na tunnel. O nagbabalik ang isang save call ng error na walang ipinaliwanag, o idinedeklarang nawawala ang isang shared secret ilang segundo matapos itong italaga. Tatlong sintomas, isang mekanismo: ang manager ay isang view sa isang system store, at ang view ay binabasang walang laman hanggang may mag-load nito.

Bago i-debug ang alinman sa mga ito, magpasya kung aling API ang dapat mong gamitin. Ang system IPsec o IKEv2 tunnel ay bagay sa built-in na manager; ang protocol na hindi ipinapatupad ng system ay nangangailangan ng tunnel provider na may sarili mong paghawak ng packet, at walang kumbinasyon ng field ang makakabago niyon.

Ang manager ay isang view sa isang store

Gumawa o kumuha ng manager, hilingin itong i-load ang mga kagustuhan nito, at hayaang matapos ang completion handler bago magbasa ng status o magbago ng mga setting ng protocol. Kapag ang gawain ay ilista ang mga naka-save na configuration, gamitin ang call para sa lahat ng variant sa halip na gamitin muli ang isang instance para sa dalawang layunin. Bago dumating ang pag-load, karaniwang di-wasto ang status, at ang gawing patay ang di-wasto ay siya mismong bug na nagpapamukhang mali ang app pagkatapos lamang ng restart.

Ang pagsulat ay sumusunod sa parehong pagkakasunod-sunod. Ang pag-save na sinubukan sa isang manager na kailanman ay walang na-load ay maaaring mabigo nang walang kapaki-pakinabang na mensahe, dahil walang naka-save na pagkakakilanlan na paglalapatan ng pagbabago. I-load, baguhin, i-save, pagkatapos basahin muli ang status. Ang object na kinokonektahan ng system ay ang naka-save na profile, hindi ang ine-edit mo sa memorya.

Ang mga pagbabago ng status ay dumarating lamang habang nakatingin ka

Kapag na-load na ang mga kagustuhan, dumadaan ang status sa di-konektado, kumokonekta, konektado, muling nagpapatunay at dumidiskonekta. Simulan ang interface sa isang pagbasa, pagkatapos makinig sa notification ng pagbabago sa halip na mag-poll gamit ang timer. Gumagana ang polling sa harapan at nagsisinungaling sa likuran, at ganoon napupunta ang mga app sa isang spinner na hindi kailanman nalulutas.

Dumarating lamang ang mga notification habang ang app ay nasa harapan. Anumang nagpapanatili ng status sa likuran ay magmumukhang luma pagkatapos ng restart, kaya i-refresh sa paglunsad at muli kapag bumabalik ang app sa harapan. Kung pag-aari ng provider ang tunnel, patakbuhin ito sa pamamagitan ng katugmang session object; ang simpleng connection property ay hindi nagmomodelo ng lifecycle ng provider.

Ang mga secret ay reperensya, hindi string

Ang ulat na nawawala ang isang shared secret ay bihirang nangangahulugang walang nagtalaga ng isa. Ang protocol object ay gusto ng reperensya: isa para sa password ng user at isa para sa pre-shared key ng IPsec. Ang pagpasa ng nil, o ng reperensyang hinango sa maling keychain entry, ay nagbibigay ng parehong reklamo gaya ng walang laman na slot. Pinapangalanan ng error ang sintomas at itinatago ang dahilan, kaya paulit-ulit na ipinapasok ng mga tao ang parehong secret.

Isulat muna ang secret bilang generic na password item, pagkatapos basahin pabalik ang isang persistent na reperensya dito. Ang persistent na reperensya ay tumatagal pagkatapos ng restart, hindi tulad ng pointer na hawak sa memorya, at iyon ang representasyong sini-serialize ng profile. Pumili ng accessibility class na pumapayag pa rin ng access kapag na-unlock na ang device, kung hindi, ang tunnel na kailangang kumonekta muli sa naka-lock na screen ay mabibigo sa authentication kahit ganap na wastong secret.

May sariling keychain view ang extension

Ang network extension ay hiwalay na proseso, kaya hindi umaabot doon ang default na keychain access ng app. Bigyan ang parehong target ng parehong keychain access group sa kanilang mga entitlement, i-save ang item nang isang beses sa loob ng grupong iyon, at hayaang basahin ito ng bawat proseso. Kung walang grupo, wala itong makikita ang extension at mag-uulat ng pagkabigo sa kredensyal na hindi kayang kopyahin ng app.

Kung ang provider ay naka-configure sa pamamagitan ng provider configuration object nito, huwag ding i-embed ang secret sa loob ng app. Nagkakaiba ang dalawang kopya, at ang pagkakaiba ay lumalabas bilang masamang kredensyal sa halip na bilang duplikasyon. Ang widget o pangalawang proseso na nag-uulat ng ibang status ay may parehong paliwanag: kailangan ng bawat isa ang grupo, at kailangang i-load ng bawat isa ang mga kagustuhan bago magbasa.

Itugma ang API sa protocol

Ang built-in na manager ay nagdadala ng IPsec at IKEv2 protocol object. Hindi ito nagiging generic na SSL VPN client sa pamamagitan ng karagdagang field, at ang hindi tugmang profile ay maaaring malinis na ma-save at gayon pa man ay hindi kailanman kumonekta. Magpasya kung saang kategorya ka kabilang bago siyasatin ang status, dahil ang bug sa status at ang hindi suportadong protocol ay magkamukha mula sa labas.

Para sa susunod na paglunsad, maikli ang checklist: i-load ang mga kagustuhan, basahin ang status, panatilihin ang mga subscription sa pagbabago sa harapan, muling buuin ang mga reperensya mula sa shared group, at kumpirmahin na tumutugma ang protocol object sa API na inimplementa mo. Ang pagdaan sa listahang iyon ay tumatagal ng isang minuto; ang paghula tungkol dito ay tumatagal ng isang hapon.