In aktive VPN detektearje yn in sandboxed Mac-app

Der is gjin iepenbiere API foar dizze fraach, en de trúk mei de ynterface-namme is mar in heuristyk. Seis kontrôles om te beslissen wêr't jo app echt fan ôfhinklik wêze moat.

Jo hawwe ien skerm nedich dat oars hâldt en draacht as de tunnel oan is, en der is gjin oprop dy't jo dat fertelt. Dat is de beheining by it útjaan: op macOS rapportearret gjin iepenbier ramt oft in willekeurige VPN ferbûn is, en op iOS heart de status by de app dy't de konfiguraasje ynstallearre hat. De kontrôles hjirûnder geane fan dy grins nei eat dat jo útjaan kinne, en elk fan harren kin it sykjen betiid einigje.

Kontrôle 1: is de fraach wol te beäntwurdzjen?

Sandboxing beslút de fraach foardat hokker API dan ek dat docht. In proses fan in tredde partij kin de ekstinsje fan in oare leveransier net opsomme en kin de konfiguraasje fan dy ekstinsje ek net lêze, dus der is gjin stipe objekt om te freegjen.

Elke omwei stjit op deselde muorre. Ynterface-listen, scutil --nc list en direkte lêzingen fan systeemkonfiguraasje freegje itsij rjochten dy't it sandbox efterhâldt, itsij binne se ôfhinklik fan gedrach dat Apple nea beloofd hat. As it plan ien fan dy nedich hat, is it plan it probleem. In funksje boud op in ûndokumintearre detail is in stipekaart mei in leveringsdatum.

Kontrôle 2: beheart jo app de tunnel sels?

As dat sa is, hawwe jo in stipe antwurd foar jo eigen konfiguraasje. Laad de foarkarren, behannelje de flater, lês dan de status en abonnearje jo op feroaringen ynstee fan te polljen:

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
}

Wês presiis oer wat dit weromjout: de tastân fan de tunnel dy't jo ynstallearre hawwe. In brûker dy't in oare klant draait, sil as loskeppele ferskine, en dat is gjin bug yn jo koade. Beslis hokker fan dy twa fragen jo funksje echt stelt foardat jo op it antwurd bouwe.

Kontrôle 3: wat soe in heuristyk jo eins fertelle?

De breed kopiearre oanpak freget it systeem-proxywurdboek om syn beskoattele yngongen en lêst de kaaien, dy't tafallich ynterface-nammen binne:

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

In kaai dy't begjint mei tap, tun, ppp, ipsec of utun ymplisearret dat der in tunnel-beskoattele ynterface oanwêzich is. It hiele namme ferlykje mislearret daliks, om't iOS 12 mei utun1 en utun2 kaam en guon profilen as ipsec4, ppp0 of utun0 ferskine. Ferlykje foarheaksels ynstee.

Dochs identifisearret in namme gjin eigener. Systeemfunksjes en ekstinsjes fan oare leveransiers meitsje ek utun-ynterfaces, en ien kin bestean wylst er neat fan jo ferkear draacht. Lês it as in hint dat der eat tunnel-foarmich yn 'e buert is, net sterker. In falsk posityf is hjir goedkeap as jo mar ien funksje ôfskermje, en djoer as jo it oanmeldskerm ôfskermje.

Kontrôle 4: kinne jo ynstee it bestimming testen?

As de app allinnich witte moat oft in ynterne tsjinst berikber is, testje dy tsjinst. In koarte probe mei in tiidlimit beantwurdet de fraach dêr't de funksje echt fan ôfhinklik is, en it bliuwt wurkjen as de brûker fan klant feroaret of de tunnel fan foarm feroaret.

Berikberens is in observaasje oer jo paad. In ynterface-namme is in konklúzje oer eat dat grinzet oan jo paad, en dêrom produsearret de heuristyk diskusjes yn bugrapporten en de probe bewiis. As de probe mislearret wylst de brûker derop stiet dat de VPN oan is, hawwe jo no in konkreet paad om te debuggen: namme-oplossing, rûte of tsjinstrjocht.

Kontrôle 5: kin it platfoarm ôftwinge wat jo nedich hawwe?

As de eask in garânsje is dat neat út de tunnel ûntkomt, heart it profyl dêr, net de detektor. It oansetten fan includeAllNetworks yn in folsleine-tunnelkonfiguraasje op iOS 14 of letter feroaret it gedrach fan it platfoarm ynstee fan jo app te freegjen it ôf te lieden. De flagge is dokumintearre yn de NEVPNProtocol-referinsje.

Dat is in oar soart antwurd: ôftwinging ynstee fan observaasje. It jildt ek allinnich foar profilen dy't jo beheare, dus it helpt in konsuminte-app net dy't de tunnel fan in oar yn 'e gaten hâldt.

Kontrôle 6: meitsje it mislearjen feilich en waarnimber

Skeakelje allinnich de kapasiteit út dy't de tunnel nedich hat en lit de rest fan 'e app brûkber. In detektor dy't de hiele ynterface ferberget wannear't er ûnwis is, makket in útfal foar elkenien waans tunnel in namme brûkt dy't jo nea ferwachte hiene. Fal ynstee werom op it konservative gedrach: lokale funksjes bliuwe wurkjen en allinnich de ôfstânsoprop dy't echt de tunnel nedich hat, wurdt útskeakele. Dy kar is in produktbeslissing, en hy fertsjinnet om njonken de heuristyk skreaun te wurden.

Log wat jo observearre hawwe: ynterface-nammen, platfoarmferzje en it resultaat fan ien probe. Dat makket it folgjende rapport fan in diskusje ta in kontrôle. Ferkenne dan in stipe ferklearring wêr't jo dy hawwe, om't in beheard konfiguraasje de bedoeling eksplisyt drage kin en it measte fan 'e reden om nammen te ynspektearjen hielendal fuorthelje kin.

As kontrôles 1 oant 5 jo sûnder in stipe antwurd litten hawwe, leverje dan de probe út en labelje it resultaat earlik. In dokumintearre bêst-mooglik-sinjaal is in bettere produktbeslissing as in privee API dy't by de folgjende útjefte brekt.

Relatearre artikelen