Bakit nagpapakita ng disconnected ang iOS VPN app mo habang tumatakbo ang tunnel
Kinokontrol ng iyong iOS app ang tunnel pero hindi ito pag-aari nito, at ang estado ng manager ay naka-cache. I-load muna ang mga preference, pagkatapos basahin ang status at mga counter ng interface.
Sinasabi ng app mo na disconnected, sabi ng menu bar ay connected, at malinaw na dumadaloy ang trapiko. Hindi ito race condition na maaayos sa muling pagsubok: magkaibang proseso ang app at ang tunnel, at ang object na binabasa ng code mo ay naka-cache na view ng configuration na iniimbak ng system. Ang Personal VPN surface ng Apple ay control API, hindi data path, at karamihan ng kakaibang ugali nito ay nagmumula sa isang katotohanang iyon. Narito ang tunay na nangyayari sa bawat tawag.
Ang object ng manager ay naka-cache na view, hindi ang tunnel
NETunnelProviderManager ay pinupuno mula sa isang preference store na pag-aari ng system, kaya wala pang ibig sabihin ang mga property nito hanggang matapos ang loadFromPreferences. Kung basahin mo ang connection.status bago iyon, makakakuha ka ng default na halaga, at iyon ang dahilan kung bakit ang unang status refresh pagkatapos ng relaunch ay nag-uulat ng disconnected habang tumatakbo ang tunnel. Mag-load muna, pagkatapos basahin ang status at protocol configuration mula sa parehong completion handler. Obserbahan ang mga susunod na pagbabago sa pamamagitan ng NEVPNStatusDidChange sa halip na mag-poll, at tandaan na umaandar din ang notification para sa mga koneksyong sinimulan ng On Demand, kung saan wala talagang tawag ng app na makakapagbalik ng kahit ano. Ganoon din sa mga setting ng protocol: binabasa ang mga ito mula sa na-load na configuration, hindi mula sa ipinasa ng app.
Ang tunnel mismo ay naninirahan sa isang proseso ng provider ng Network Extension, kaya maaaring mawala ng app ang sarili nitong estado nang hindi nawawala ang koneksyon. Lahat ng ipinapakita ng interface ay dapat itayong muli mula sa manager, hindi alalahanin mula sa nakaraang session.
Pagkakasunod-sunod ng pagsisimula: i-save, i-load, pagkatapos simulan
Ang koneksyong nakabatay sa provider ay nangangailangan ng tatlong hakbang sa ayos. Isulat ang configuration ng provider at tawagin ang saveToPreferences, i-load ang manager upang ang na-save na configuration ang hawak mo, pagkatapos simulan sa pamamagitan ng NETunnelProviderSession.startVPNTunnel(). Kung lalaktawan mo ang pag-save, wala nang isisimula ang pagsisimula; kung mag-load ka bago mag-save, ang manager ay sumasalamin pa rin sa lumang configuration.
Ang boolean na ibinabalik ng startVPNTunnel ay nagsasabi lamang na tinanggap ang kahilingan. Dumarating ang mga pagkabigo sa antas ng provider sa kalaunan bilang pagbabago ng status tungong disconnected, na napapansin mo sa pamamagitan ng notification na NEVPNStatusDidChange, at kailangang muling basahin ng notification handler ang connection.status pagkatapos ng loadFromPreferences dahil maaaring luma pa rin ang naka-cache na halaga. Ang mga pagkabigo sa antas ng kahilingan ay agad na bumabalik mula sa anyong nagtatapon ng exception ng tawag, o sa pamamagitan ng error out-parameter ng startVPNTunnelAndReturnError:. Ang code na itinuturing na resulta ang return value ay nag-uulat ng koneksyong hindi kailanman naitatag. Ang isa pang tahimik na pagkabigo ay ang bundle identifier ng provider na hindi tumutugma sa naka-install na extension: tinatanggihan ang kahilingan, at wala sa mensahe ang tumuturo sa identifier. Kung mali ang identifier, karaniwang nabibigo agad ang kahilingan, bago pa man lumitaw ang anumang log line ng provider.
Ang muling pag-load ng mga preference pagkatapos ng pagsisimula ang nagpapaging tama sa mga status screen. Hindi ka tinutulak ng manager ng bagong configuration kapag binago ito ng system.
Dumarating ang trust material sa pamamagitan ng profile, hindi kailanman mula sa code ng app
Walang sinusuportahang paraan ang app para magdagdag ng root certificate sa trust store ng iOS, kaya ang isang Personal VPN configuration ay makakarefer lamang ng materyal na pinagkakatiwalaan na ng device: isang chain na itinatag ng naka-install na profile, ng device management, o ng CA na pinagkakatiwalaan ng system sa ibang dahilan. Ang app na gumagawa ng sarili nitong CA sa unang paglulunsad at umaasang tatanggapin ito ng system ay mabibigo sa validation sa loob ng provider, kung saan hindi nakikita ng interface ng app ang dahilan.
Ituring ang hangganang iyon bilang design constraint na talaga namang gayon, at ipadala ang trust anchor kasama ng enrollment profile. Panatilihing hiwalay ang VPN authentication mula sa desisyon sa pagtitiwala, dahil nabibigo sila sa magkaibang lugar at magkaibang tao ang nagde-debug sa kanila.
Galing sa interface ang mga counter, hindi sa VPN API
Inilalantad ng manager ang status at configuration, at wala sa anumang bumabibilang ng byte kada tunnel. Kung kailangan mo ng mga numero ng paggamit, tawagin ang getifaddrs() at basahin ang if_data para sa kaugnay na interface: en0 para sa Wi-Fi, ang mga interface na pdp_ip para sa cellular, at device na utun para sa tunnel mismo. Inilalarawan ng mga counter ng utun ang panloob na trapiko at kasama ang overhead ng protocol.
Ang mga numerong ito ay tantya, hindi accounting kada app, at nagre-reset ang mga ito kapag muling ginawa ang interface. Lagyan ng ganoong label sa interface, kung hindi ay gagamitin ito ng iba para singilin ang isang customer. Kung kailangan mo ng numero kada app, kailangan mo ng lubos na ibang mekanismo, hindi mas mahusay na pagbasa ng mga field na ito.
Ang paglilinis ay nasa stopVPNTunnel, hindi sa termination
applicationWillTerminate ay nagbibigay sa iyo ng ilang segundo bago maaaring patayin ng system ang proseso, at hindi iyon maaasahang lugar para ibagsak ang isang koneksyon. Ipadala ang stop sa stopVPNTunnel() o pangasiwaan ito sa stop callback ng provider, at itago ang manager o configuration identifier na sinimulan mo, upang ang stop ay tumutok sa koneksyong iyon at hindi sa lahat ng configuration sa device.
Itago ang identifier na iyon sa tabi ng profile kung saan ito kabilang, dahil hindi itinatala ng manager object kung aling configuration ang pinili ng user. At tandaan na ang koneksyong itinataas ng On Demand ay walang anumang tawag ng app sa likod nito, kaya ang status screen ay kailangan pa ring mag-load ng mga preference bago ito gumuhit ng kahit ano.