Pag-detect ng aktibong VPN sa loob ng sandboxed na Mac app

Kailangan mo ng isang screen na kumilos nang iba kapag naka-on ang tunnel, at walang tawag na magsasabi nito sa iyo. Ito ang hadlang sa pagpapalabas: sa macOS walang pampublikong framework na nag-uulat kung konektado ang isang arbitrary na VPN, at sa iOS ang status ay pag-aari ng app na nag-install ng configuration. Ang mga pagsusuri sa ibaba ay mula sa hangganang iyon patungo sa isang bagay na maaari mong ilabas, at alinman sa mga ito ay maaaring tapusin ang paghahanap nang maaga.

Pagsusuri 1: masasagot ba ang tanong kahit papaano?

Ang sandbox ay nagtatakda ng tanong bago pa gawin ito ng anumang API. Ang proseso ng third party ay hindi makakapag-enumerate ng extension ng ibang vendor, at hindi rin nito mababasa ang configuration ng extension na iyon, kaya walang sinusuportahang object na matatanong.

Bawat pag-iwas ay bumangga sa parehong pader. Ang mga listahan ng interface, scutil --nc list at ang direktang pagbasa ng configuration ng system ay nangangailangan ng mga pahintulot na pinipigilan ng sandbox o umaasa sa pag-uugali na hindi kailanman ipinangako ng Apple. Kung kailangan ng plano ang isa sa mga ito, ang plano ang problema. Ang feature na itinayo sa hindi dokumentadong detalye ay isang support ticket na may petsa ng paghahatid.

Pagsusuri 2: pinamamahalaan ba ng iyong app ang tunnel mismo?

Kung oo, mayroon kang sinusuportahang sagot para sa iyong sariling configuration. I-load ang mga kagustuhan, pangasiwaan ang error, pagkatapos basahin ang status at mag-subscribe sa mga pagbabago sa halip na mag-poll:

vpnManager.loadFromPreferences { error in
    // handle a load failure before reading status
}

NotificationCenter.default.addObserver(
    forName: .NEVPNStatusDidChange,
    object: nil,
    queue: nil
) { note in
    let status = (note.object as? NEVPNConnection)?.status
}

Maging tumpak tungkol sa ibinabalik nito: ang estado ng tunnel na in-install mo. Ang user na gumagamit ng ibang client ay lalabas na hindi konektado, at hindi iyon bug sa iyong code. Magpasya kung alin sa dalawang tanong na ito ang tunay na tinatanong ng iyong feature bago magtayo sa sagot.

Pagsusuri 3: ano talaga ang sasabihin sa iyo ng isang heuristic?

Ang malawakang kinopyang paraan ay nagtatanong sa proxy dictionary ng system para sa mga scoped entry nito at binabasa ang mga key, na nagkataong mga pangalan ng interface:

let settings = CFNetworkCopySystemProxySettings()?.takeRetainedValue() as NSDictionary?
let scoped = settings?["__SCOPED__"] as? [String: Any]
let names = scoped?.keys ?? []

Ang isang key na nagsisimula sa tap, tun, ppp, ipsec o utun ay nagpapahiwatig na may interface na may saklaw ng tunnel. Nabibigo agad ang pagtutugma ng buong pangalan, dahil ang iOS 12 ay may utun1 at utun2 at ang ilang profile ay lumalabas bilang ipsec4, ppp0 o utun0. Ikumpara ang mga prefix sa halip.

Gayunpaman, walang tinutukoy na may-ari ang isang pangalan. Ang mga feature ng system at extension ng ibang vendor ay gumagawa rin ng utun interface, at may isa na maaaring umiral nang walang bitbit na anuman sa iyong traffic. Basahin ito bilang pahiwatig na may isang bagay na hugis tunnel sa malapit, wala nang higit pa. Ang false positive dito ay mura kung isang feature lang ang iyong hinaharang, at mahal kung ang login screen ang hinaharang mo.

Pagsusuri 4: maaari mo bang subukan ang destinasyon sa halip?

Kung kailangan lang malaman ng app kung maaabot ang isang panloob na serbisyo, subukan ang serbisyong iyon. Ang maikling probe na may timeout ay sumasagot sa tanong na talagang pinagbabasehan ng feature, at patuloy itong gumagana kapag nagpalit ng client ang user o nagbago ng hugis ang tunnel.

Ang maabot ay isang obserbasyon tungkol sa iyong landas. Ang pangalan ng interface ay isang hinuha tungkol sa isang bagay na katabi ng iyong landas, kaya ang heuristic ay gumagawa ng mga pagtatalo sa mga ulat ng bug at ang probe ay gumagawa ng ebidensya. Kung nabigo ang probe habang iginiit ng user na naka-on ang VPN, mayroon ka nang konkretong landas na i-debug: resolution ng pangalan, ruta o pahintulot ng serbisyo.

Pagsusuri 5: maaari bang ipatupad ng platform ang kailangan mo?

Kapag ang pangangailangan ay isang garantiya na walang tumatakas sa tunnel, ang profile ang lugar nito, hindi ang detector. Ang pag-on ng includeAllNetworks sa isang full-tunnel configuration sa iOS 14 o mas bago ay nagbabago ng pag-uugali ng platform sa halip na hilingin sa iyong app na hinuha ito. Ang flag ay dokumentado sa reference ng NEVPNProtocol.

Ito ay ibang uri ng sagot: pagpapatupad sa halip na obserbasyon. Naaangkop din ito sa mga profile na kinokontrol mo lang, kaya hindi nito natutulungan ang isang consumer app na nanonood ng tunnel ng ibang tao.

Pagsusuri 6: gawing ligtas at nakikita ang kabiguan

Patayin lamang ang kakayahang nangangailangan ng tunnel at iwanang magagamit ang natitirang bahagi ng app. Ang detector na nagtatago ng buong interface sa tuwing hindi ito sigurado ay gumagawa ng pagkawala ng serbisyo para sa sinumang ang tunnel ay gumagamit ng pangalan na hindi mo inaasahan. Bumalik sa konserbatibong pag-uugali sa halip: patuloy na gumagana ang mga lokal na feature at ang tanging malayong tawag na talagang nangangailangan ng tunnel ang hindi pinagana. Ang pagpipiliang iyon ay isang desisyon sa produkto, at karapat-dapat itong isulat sa tabi ng heuristic.

I-log ang iyong naobserbahan: mga pangalan ng interface, bersyon ng platform at resulta ng isang probe. Ginagawa nitong pagsusuri ang susunod na ulat mula sa pagtatalo. Pagkatapos ay unahin ang sinusuportahang deklarasyon kung mayroon ka, dahil ang pinamamahalaang configuration ay maaaring magdala ng intensyon nang tahasan at alisin ang karamihan ng dahilan upang siyasatin ang mga pangalan.

Kung iniwan ka ng mga pagsusuri 1 hanggang 5 na walang sinusuportahang sagot, ilabas ang probe at lagyan ng label ang resulta nang tapat. Ang dokumentadong senyales ng pinakamabuting pagsisikap ay isang mas mahusay na desisyon sa produkto kaysa sa isang pribadong API na masisira sa susunod na release.