Pam mae eich ap VPN iOS yn dangos datgysylltiedig tra bo’r twnnel yn rhedeg

Mae eich ap yn dweud datgysylltiedig, mae’r bar dewislen yn dweud cysylltiedig, ac mae’r traffig yn amlwg yn llifo. Nid cyflwr ras yw’r bwlch hwnnw y gallwch ei drwsio ag ailgynnig: mae’r ap a’r twnnel yn brosesau ar wahân, ac mae’r gwrthrych y mae eich cod yn ei ddarllen yn olwg wedi’i chadw o gyfluniad y mae’r system yn ei storio. Mae wyneb Personal VPN Apple yn API rheoli, nid yn lwybr data, ac mae’r rhan fwyaf o’i ymddygiad od yn deillio o’r ffaith honno’n unig. Dyma beth sy’n digwydd mewn gwirionedd o dan bob galwad.

Mae gwrthrych y rheolwr yn olwg wedi’i chadw, nid y twnnel

NETunnelProviderManager yn cael ei lenwi o storfa dewisiadau sy’n eiddo i’r system, felly nid yw ei briodweddau’n golygu dim nes bod loadFromPreferences wedi gorffen. Darllenwch connection.status cyn hynny a chewch werth diofyn, a dyna pam mae’r adnewyddiad statws cyntaf ar ôl ailgychwyn yn adrodd datgysylltiedig tra mae’r twnnel i fyny. Llwythwch yn gyntaf, yna darllenwch y statws a chyfluniad y protocol o’r un triniwr cwblhau. Arsyliwch newidiadau diweddarach drwy NEVPNStatusDidChange yn lle arolygu, a nodwch fod y hysbysiad hefyd yn tanio ar gyfer cysylltiadau a gychwynnwyd gan On Demand, lle nad oes galwad ap yn bodoli i ddychwelyd unrhyw beth o gwbl. Mae’r un peth yn wir am osodiadau protocol: cânt eu darllen o’r cyfluniad a lwythwyd, nid o’r hyn y gwnaeth yr ap ei basio i mewn.

Mae’r twnnel ei hun yn byw mewn proses darparwr Network Extension, felly gall yr ap golli ei gyflwr ei hun heb golli’r cysylltiad. Rhaid ailadeiladu popeth y mae’r rhyngwyneb yn ei ddangos o’r rheolwr, nid ei gofio o’r sesiwn ddiwethaf.

Trefn cychwyn: cadw, llwytho, yna cychwyn

Mae cysylltiad sy’n seiliedig ar ddarparwr angen tri cham yn eu trefn. Ysgrifennwch gyfluniad y darparwr a galwch saveToPreferences, llwythwch y rheolwr fel mai’r cyfluniad a gadwyd yw’r un sydd gennych, yna cychwynnwch drwy NETunnelProviderSession.startVPNTunnel(). Os hepgorwch y cadw, nid oes gan y cychwyn ddim i’w lansio; os llwythwch cyn y cadw, mae’r rheolwr yn dal i adlewyrchu’r hen gyfluniad.

Nid yw’r Boole a ddychwelwyd gan startVPNTunnel yn dweud ond bod y cais wedi’i dderbyn. Daw methiannau ar lefel darparwr yn ddiweddarach fel newid statws i ddatgysylltiedig, yr ydych yn ei arsyli drwy hysbysiad NEVPNStatusDidChange, a rhaid i driniwr yr hysbysiad ail-ddarllen connection.status ar ôl loadFromPreferences oherwydd efallai bod y gwerth a gedwir yn dal yr hen un. Daw methiannau ar lefel cais yn ôl ar unwaith o ffurf taflu’r alwad, neu drwy’r paramedr allanol gwall startVPNTunnelAndReturnError:. Mae cod sy’n trin y gwerth a ddychwelwyd fel y canlyniad yn adrodd cysylltiad na sefydlwyd erioed. Y methiant tawel arall yw dynodydd bwndel darparwr nad yw’n cyfateb i’r estyniad sydd wedi’i osod: gwrthodir y cais, ac nid oes dim yn y neges yn cyfeirio at y dynodydd. Os yw’r dynodydd yn anghywir, mae’r cais fel arfer yn methu ar unwaith, cyn i unrhyw linell log darparwr ymddangos.

Ail-lwytho dewisiadau ar ôl cychwyn yw’r hyn sy’n gwneud sgriniau statws yn gywir. Nid yw’r rheolwr yn gwthio cyfluniad newydd atoch pan fydd y system yn ei newid.

Daw deunydd ymddiriedaeth drwy broffil, byth o god yr ap

Nid oes gan ap unrhyw ffordd â chefnogaeth i ychwanegu tystysgrif gwraidd at storfa ymddiriedaeth iOS, felly gall cyfluniad Personal VPN gyfeirio at ddeunydd y mae’r ddyfais eisoes yn ymddiried ynddo yn unig: cadwyn a sefydlwyd gan broffil sydd wedi’i osod, gan reolaeth dyfais, neu gan CA y mae’r system yn ymddiried ynddo am resymau eraill. Bydd ap sy’n bathu ei CA ei hun ar y lansiad cyntaf ac yn disgwyl i’r system ei anrhydeddu yn methu’r dilysiad y tu mewn i’r darparwr, lle na all rhyngwyneb yr ap weld y rheswm.

Triniwch y ffin honno fel y cyfyngiad dylunio ydyw a llongwch yr angor ymddiriedaeth gyda’r proffil cofrestru. Cadwch ddilysu VPN ar wahân i’r penderfyniad ymddiriedaeth, oherwydd maent yn methu mewn gwahanol leoedd ac yn cael eu dadfygio gan wahanol bobl.

Daw cyfrifwyr o’r rhyngwyneb, nid o’r API VPN

Mae’r rheolwr yn datgelu statws a chyfluniad, a dim byd sy’n cyfrif beitiau fesul twnnel. Os oes angen rhifau defnydd arnoch, galwch getifaddrs() a darllenwch if_data ar gyfer y rhyngwyneb perthnasol: en0 ar gyfer Wi-Fi, y rhyngwynebau pdp_ip ar gyfer symudol, a dyfais utun ar gyfer y twnnel ei hun. Mae cyfrifwyr utun yn disgrifio’r traffig mewnol ac yn cynnwys treuliant y protocol.

Mae’r ffigurau hynny’n amcangyfrifon, nid cyfrif fesul ap, ac maent yn ailosod pan ail-grëir y rhyngwyneb. Labelwch hwy felly yn y rhyngwyneb, neu bydd rhywun yn eu defnyddio i filio cwsmer. Os oes angen rhifau fesul ap arnoch, mae angen mecanwaith hollol wahanol arnoch, nid darlleniad gwell o’r meysydd hyn.

Mae glanhau’n perthyn i stopVPNTunnel, nid i derfynu

applicationWillTerminate yn rhoi ychydig eiliadau i chi cyn y gall y system ladd y broses, ac nid yw hynny’n lle dibynadwy i ddarnio cysylltiad. Anfonwch yr atal i stopVPNTunnel() neu triniwch ef yng nghalad ôl atal y darparwr, a chadwch y dynodydd rheolwr neu gyfluniad y gwnaethoch gychwyn ag ef fel bod yr atal yn targedu’r cysylltiad hwnnw yn lle pob cyfluniad ar y ddyfais.

Storiwch y dynodydd hwnnw ochr yn ochr â’r proffil y mae’n perthyn iddo, gan nad yw gwrthrych rheolwr yn cofnodi pa gyfluniad a ddewisodd y defnyddiwr. A chofiwch nad oes gan gysylltiad a ddygwyd i fyny gan On Demand unrhyw alwad ap y tu ôl iddo o gwbl, felly rhaid i sgrin statws lwytho dewisiadau o hyd cyn iddi dynnu unrhyw beth.