Ano ang Kayang Gawin ng NEVPNManager sa iOS (at Ano ang Hindi)

Kapag gumawa ka ng VPN screen sa loob ng isang iOS app, ang unang sorpresa ay ang listahan ng protocol sa Settings app ay hindi ang listahan ng API. Hinihintulutan ka ng Network Extension framework na gumawa ng isang personal na VPN configuration, na pag-aari ng app na iyon, at kakaunting protocol object lang ang tinatanggap nito. Ang iba pang inaasahan ng mga tao, mula L2TP hanggang sa isang na-download na profile, ay nasa labas ng surface na iyon o pribado para sa Apple. Ang mga sumusunod na pagkabigo ay kadalasang hindi bug, ang API ang tumatanggi sa isang trabahong hindi naman ibinigay dito.

Ang alamat: ang API ay editor ng Settings

Ipinapalagay na dahil kayang i-configure ng iOS ang mga profile na IKEv1, IKEv2, L2TP at IPsec, kayang gumawa ng app ng alinman sa mga ito sa paraang programa. Hindi nito kaya. Ang framework ay naglalabas ng eksaktong isang configuration slot sa tumatawag na app, at ang slot na iyon ay kakaunting pampublikong protocol class lang ang tinatanggap. Ang iba pang inaasahan ng mga tao, mula L2TP hanggang sa isang na-download na profile, ay nasa labas ng surface na iyon o pribado para sa Apple.

Ang mga sumusunod na pagkabigo ay kadalasang hindi bug. Ang API ang tumatanggi sa isang trabahong hindi naman ibinigay dito, at ang lunas ay idisenyo ang screen sa paligid ng pag-aari ng API.

Tatlong protocol object at ang mga wala

Ang mga opsyon mo ay IKEv1 sa pamamagitan ng NEVPNProtocolIPSec, IKEv2 sa pamamagitan ng NEVPNProtocolIKEv2, at NETunnelProviderProtocol kung maghahatid ka ng sarili mong packet tunnel extension. Inililista ng NEVPNManager reference ang mga tinatanggap na protocol object. Hindi kailanman lumalabas ang L2TP at PPTP sa listahang iyon dahil walang inilathalang klase ang Apple para sa kanila. Ang pagsubok sa alinman sa dalawa ay nagtatapos sa pag-save na may error, o mas malala, sa isang configuration na tahimik na tinatanggihan ng system na gamitin.

Ang desktop code ay sumusunod sa ibang mga tuntunin. Sa macOS, ang SCNetworkInterfaceCreateWithInterface ay nagstack ng isang uri ng interface tulad ng L2TP sa ibabaw ng IPv4 at ikinakabit ito sa isang serbisyo ng network, at ang networksetup -connectpppoeservice ay nagsisimula ng resulta. Kailangan ang mga karapatan ng administrator at isang helper tool, dahil napupunta sa system keychain ang shared secret at password. Kopyahin mo ang design na iyon sa iOS at walang magko-compile.

Magpasa ng keychain reference, hindi password

Wala sa dalawang IKE class ang tumatanggap ng password bilang teksto. Ang dalawang property na passwordReference at sharedSecretReference ay gusto ng persistent keychain reference, na nakukuha mo mula sa SecItemCopyMatching sa pamamagitan ng paghingi ng kSecReturnPersistentRef. Ang pagpasa ng data ng item, o pagpasok ng string sa field, ay gumagawa ng pag-save na bigo o isang koneksyon na may blangkong kredensyal. Ang reference ay matibay lamang hangga't ang keychain item sa likod nito, kaya dapat na umiiral ang item bago buuin ang configuration. Gumawa ito sa parehong transaksyon ng pag-save at aalisin mo ang isang buong klase ng bug sa pagkasunod-sunod.

Ang authentication ng certificate ay ibang ruta: identityData dagdag ang identityDataPassword para sa isang blob na PKCS#12. Ang paghahatid ng blob na iyon sa loob ng bundle ng app ay isang ugali mula sa sample na code, hindi isang desisyon sa paglabas, dahil naglalakbay ang password kasama nito at ang bawat kopya ng app ay may dalang parehong pagkakakilanlan.

Ang karapatan at pagkakaroon ay naghaharang sa lahat

Maaaring wala talaga ang manager, at ang dahilan ay provisioning. Ang identifier ng app mo ay nangangailangan ng Network Extension capability kasama ang karapatan para sa personal na VPN, at ang profile na pumipirma sa build ay dapat may dalang dalawa.

Laktawan mo iyon at ang shared instance ay nagbabalik ng nil, o nabibigo ang pag-save na may error na hindi kailanman binabanggit ang karapatan. Ang pagkakaroon ay ang isa pang tarangkahan. Kung i-target mo ang mas luma kaysa iOS 8, wala ang simbolo sa runtime, kaya ang pagkabigo ay isang crash o nil manager, hindi isang manager na walang configuration. Suriin ang runtime at ang karapatan bago i-debug ang object graph mo.

I-load, baguhin, i-save, pagkatapos panoorin ang pagkakasunod-sunod kapag hiniling

Ituring ang lifecycle bilang load, modify, save, at huwag kailanman laktawan ang load. Hanggang sa matapos ang loadFromPreferences, wala tinataglay ang manager at hindi mababasa o mapapalitan ang protocol object.

Ang pangalawang pag-save ay pinapalitan ang configuration sa halip na magdagdag ng isa pa, kaya ang isang pag-save na kalahati ay maaaring makasira ng profile na gumagana. Ang mga panuntunan kapag hiniling ay bumubuo ng order na array, at ang order na iyon ang patakaran. Ilagay ang panuntunang kumonekta-sa-kahit-saan bago ang panuntunan ng pagdiskonekta at ang manu-manong pagdiskonekta ay sinusundan ng agarang muling pagkonekta, na mukhang depekto ngunit sumusunod sa dokumentadong pagsusuri.

Ilipat ang panuntunan ng pagdiskonekta sa unahan kapag dapat manalo ang aksyon ng user. Ang natitira sa labas ng kontrol ng app ay kasinghalaga rin. Ang mga ruta ay nagmumula sa tunnel o sa patakaran ng server sa halip na sa isang kagustuhang itinatakda mo, at iniuulat ng packet tunnel provider ang mga ito kapag nagsimula ito. Hindi kayang ilista o i-edit ng app ang mga profile na in-install ng ibang app o configuration profile, kaya huwag mangakong magpapakita ng screen na nagpapakita ng bawat VPN sa device.