Pse aplikacioni yt VPN për iOS shfaq i shkëputur ndërsa tuneli është aktiv

Aplikacioni yt thotë i shkëputur, shiriti i menusë thotë i lidhur, dhe trafiku qartë rrjedh. Ky hendek nuk është një gjendje garash që rregullohet me një provë të re: aplikacioni dhe tuneli janë procese të veçanta, dhe objekti që lexon kodi yt është një pamje e ruajtur në cache e një konfigurimi që sistemi ruan. Sipërfaqja Personal VPN e Apple është një API kontrolli, jo një rrugë të dhënash, dhe pjesa më e madhe e sjelljes së saj të çuditshme del nga ky fakt i vetëm. Ja çfarë ndodh në të vërtetë në çdo thirrje.

Objekti i menaxherit është një pamje në cache, jo tuneli

NETunnelProviderManager mbushet nga një depo preferencash që e zotëron sistemi, kështu që vetitë e tij nuk nënkuptojnë asgjë derisa loadFromPreferences të përfundojë. Nëse lexon connection.status para kësaj, merr një vlerë të parazgjedhur, dhe për këtë arsye rifreskimi i parë i statusit pas rinisjes raporton i shkëputur ndërsa tuneli është aktiv. Ngarko fillimisht, pastaj lexo statusin dhe konfigurimin e protokollit nga i njëjti trajtues përfundimi. Vëzhgo ndryshimet e mëvonshme përmes NEVPNStatusDidChange në vend të anketimit, dhe vëre se njoftimi aktivizohet edhe për lidhjet e nisura nga On Demand, ku nuk ekziston asnjë thirrje e aplikacionit që mund të kthejë diçka. E njëjta gjë vlen për cilësimet e protokollit: ato lexohen nga konfigurimi i ngarkuar, jo nga ajo që ka kaluar aplikacioni.

Vetë tuneli jeton në një proces ofruesi Network Extension, kështu që aplikacioni mund të humbasë gjendjen e vet pa humbur lidhjen. Çdo gjë që shfaq ndërfaqja duhet rindërtuar nga menaxheri, jo kujtuar nga sesioni i fundit.

Rendi i nisjes: ruaj, ngarko, pastaj nis

Një lidhje e bazuar në ofrues kërkon tre hapa me radhë. Shkruaj konfigurimin e ofruesit dhe thirr saveToPreferences, ngarko menaxherin që konfigurimi i ruajtur të jetë ai që ke në dorë, pastaj nis përmes NETunnelProviderSession.startVPNTunnel(). Nëse e anashkalon ruajtjen, nisja nuk ka çfarë të nisë; nëse ngarkon para ruajtjes, menaxheri ende pasqyron konfigurimin e vjetër.

Vlera buleane që kthen startVPNTunnel thotë vetëm se kërkesa u pranua. Dështimet në nivel ofruesi vijnë më vonë si ndryshim statusi në të shkëputur, të cilin e vëzhgon përmes njoftimit NEVPNStatusDidChange, dhe trajtuesi i njoftimit duhet të rilexojë connection.status pas loadFromPreferences sepse vlera në cache mund të jetë ende e vjetra. Dështimet në nivel kërkese kthehen menjëherë nga forma që hedh përjashtim e thirrjes, ose përmes parametrit të daljes së gabimit të startVPNTunnelAndReturnError:. Kodi që e trajton vlerën e kthyer si rezultat raporton një lidhje që nuk u vendos kurrë. Dështimi tjetër i heshtur është një identifikues pakete i ofruesit që nuk përputhet me zgjerimin e instaluar: kërkesa refuzohet, dhe asgjë në mesazh nuk tregon identifikuesin. Nëse identifikuesi është i gabuar, kërkesa zakonisht dështon menjëherë, përpara se të shfaqet ndonjë rresht log i ofruesit.

Ringarkimi i preferencave pas një nisjeje është ai që i bën ekranet e statusit të sakta. Menaxheri nuk të shtyn një konfigurim të ri kur sistemi e ndryshon atë.

Materiali i besimit vjen përmes profilit, kurrë nga kodi i aplikacionit

Një aplikacion nuk ka asnjë mënyrë të mbështetur për të shtuar një certifikatë rrënjë në depon e besimit të iOS, kështu që një konfigurim Personal VPN mund të referojë vetëm material që pajisja tashmë i beson: një zinxhir të krijuar nga një profil i instaluar, nga menaxhimi i pajisjes ose nga një CA që sistemi i beson për arsye të tjera. Një aplikacion që krijon CA-n e vet në nisjen e parë dhe pret që sistemi ta pranojë do të dështojë validimin brenda ofruesit, ku ndërfaqja e aplikacionit nuk mund ta shohë arsyen.

Trajtoje atë kufi si kufizimin e projektimit që është dhe dorëzo ankorën e besimit bashkë me profilin e regjistrimit. Mbaje vërtetimin VPN të ndarë nga vendimi i besimit, sepse ato dështojnë në vende të ndryshme dhe korrigjohen nga njerëz të ndryshëm.

Numëruesit vijnë nga ndërfaqja, jo nga API i VPN

Menaxheri ekspozon statusin dhe konfigurimin, dhe asgjë që numëron bajt për tunel. Nëse të duhen shifra përdorimi, thirr getifaddrs() dhe lexo if_data për ndërfaqen përkatëse: en0 për Wi-Fi, ndërfaqet pdp_ip për celular dhe një pajisje utun për vetë tunelin. Numëruesit e utun përshkruajnë trafikun e brendshëm dhe përfshijnë ngarkesën e protokollit.

Këto shifra janë vlerësime, jo kontabilitet për aplikacion, dhe rivendosen kur ndërfaqja rikrijohet. Etiketoji ashtu në ndërfaqe, përndryshe dikush do t'i përdorë për të faturuar një klient. Nëse të duhen shifra për aplikacion, të duhet një mekanizëm krejt tjetër, jo një lexim më i mirë i këtyre fushave.

Pastrimi i takon stopVPNTunnel, jo përfundimit

applicationWillTerminate të jep disa sekonda përpara se sistemi të mund ta vrasë procesin, dhe ky nuk është vend i besueshëm për të çmontuar një lidhje. Dërgo ndalimin te stopVPNTunnel() ose trajtoje në callback-un e ndalimit të ofruesit, dhe mbaj identifikuesin e menaxherit ose të konfigurimit me të cilin nise, që ndalimi të synojë atë lidhje në vend të çdo konfigurimi në pajisje.

Ruaj atë identifikues pranë profilit të cilit i përket, sepse objekti i menaxherit nuk regjistron cilin konfigurim zgjodhi përdoruesi. Dhe mba mend se një lidhje e ngritur nga On Demand nuk ka fare thirrje aplikacioni pas saj, kështu që një ekran statusi duhet ende të ngarkojë preferencat përpara se të vizatojë diçka.