Zbulimi i një VPN aktiv brenda një aplikacioni Mac me sandbox
Nuk ka API publike për këtë pyetje, dhe truku i emrit të ndërfaqes është vetëm një heuristikë. Gjashtë kontrolle për të vendosur se nga çfarë duhet të varet vërtet aplikacioni juaj.
Ju duhet një ekran që sillet ndryshe kur tuneli është aktiv, dhe nuk ka asnjë thirrje që ju tregon këtë. Ky është kufizimi i lëshimit: në macOS asnjë kornizë publike nuk raporton nëse një VPN arbitrare është e lidhur, dhe në iOS gjendja i përket aplikacionit që instaloi konfigurimin. Kontrollet më poshtë shkojnë nga ky kufi në diçka që mund të lëshoni, dhe secila prej tyre mund ta përfundojë kërkimin herët.
Kontrolli 1: a mund t'i jepet fare përgjigje pyetjes?
Sandbox-i e zgjidh pyetjen përpara çdo API. Një proces i palës së tretë nuk mund të numërojë shtojcën e një furnizuesi tjetër dhe nuk mund të lexojë as konfigurimin e asaj shtojce, prandaj nuk ka objekt të mbështetur për të pyetur.
Çdo anashkalim përplaset me të njëjtin mur. Listat e ndërfaqeve, scutil --nc list dhe leximet e drejtpërdrejta të konfigurimit të sistemit ose kërkojnë leje që sandbox-i i mban mbrapsht ose varen nga sjellje që Apple nuk e premtoi kurrë. Nëse plani ka nevojë për një nga këto, problemi është plani. Një veçori e ndërtuar mbi një detaj të padokumentuar është një biletë mbështetjeje me datë dorëzimi.
Kontrolli 2: a e menaxhon aplikacioni juaj vetë tunelin?
Nëse po, keni një përgjigje të mbështetur për konfigurimin tuaj. Ngarkoni preferencat, trajtoni gabimin, pastaj lexoni gjendjen dhe abonohuni në ndryshime në vend të anketimit:
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
}Jini të saktë për atë që kthen kjo: gjendjen e tunelit që instaluat. Një përdorues që ekzekuton një klient tjetër do të shfaqet si i shkëputur, dhe ky nuk është një defekt në kodin tuaj. Vendosni se cilën nga këto dy pyetje po bën vërtet veçoria juaj përpara se të ndërtoni mbi përgjigjen.
Kontrolli 3: çfarë do t'ju thoshte vërtet një heuristikë?
Qasja e kopjuar gjerësisht i kërkon fjalorit të përfaqësuesit të sistemit hyrjet e tij me fushëveprim dhe lexon çelësat, të cilët rastësisht janë emra ndërfaqesh:
let settings = CFNetworkCopySystemProxySettings()?.takeRetainedValue() as NSDictionary?
let scoped = settings?["__SCOPED__"] as? [String: Any]
let names = scoped?.keys ?? []Një çelës që fillon me tap, tun, ppp, ipsec ose utun nënkupton që është i pranishëm një ndërfaqe me fushëveprim tuneli. Përputhja e emrit të plotë dështon menjëherë, sepse iOS 12 erdhi me utun1 dhe utun2 dhe disa profile shfaqen si ipsec4, ppp0 ose utun0. Krahasoni parashtesat në vend të kësaj.
Megjithatë, një emër nuk identifikon asnjë pronar. Veçoritë e sistemit dhe shtojcat e furnizuesve të tjerë gjithashtu krijojnë ndërfaqe utun, dhe njëra mund të ekzistojë pa mbajtur asgjë nga trafiku juaj. Lexojeni si një aluzion se ka diçka në formë tuneli afër, asgjë më të fortë. Një pozitiv i rremë këtu është i lirë nëse kufizoni vetëm një veçori, dhe i shtrenjtë nëse kufizoni ekranin e hyrjes.
Kontrolli 4: a mund të provoni destinacionin në vend të kësaj?
Nëse aplikacionit i duhet vetëm të dijë nëse një shërbim i brendshëm është i arritshëm, provoni atë shërbim. Një sondë e shkurtër me afat kohor i përgjigjet pyetjes nga e cila varet vërtet veçoria, dhe vazhdon të funksionojë kur përdoruesi ndryshon klientin ose tuneli ndryshon formë.
Arritshmëria është një vëzhgim për rrugën tuaj. Emri i ndërfaqes është një konkluzion për diçka ngjitur me rrugën tuaj, prandaj heuristika prodhon debate në raportet e defekteve dhe sonda prodhon prova. Nëse sonda dështon ndërsa përdoruesi këmbëngul se VPN-ja është e ndezur, tani keni një rrugë konkrete për korrigjim: zgjidhja e emrave, rruga ose leja e shërbimit.
Kontrolli 5: a mund ta imponojë platforma atë që ju nevojitet?
Kur kërkesa është garancia që asgjë nuk shpëton nga tuneli, profili është vendi i duhur, jo zbuluesi. Aktivizimi i includeAllNetworks në një konfigurim tuneli të plotë në iOS 14 ose më të ri ndryshon sjelljen e platformës në vend që t'i kërkojë aplikacionit tuaj ta nxjerrë atë. Flamuri është dokumentuar në referencën e NEVPNProtocol.
Ky është një lloj tjetër përgjigjeje: imponim në vend të vëzhgimit. Zbatohet gjithashtu vetëm për profilet që kontrolloni, kështu që nuk ndihmon një aplikacion konsumatori që vëzhgon tunelin e dikujt tjetër.
Kontrolli 6: bëjeni dështimin të sigurt dhe të vëzhgueshëm
Fikni vetëm aftësinë që i nevojitet tunelit dhe lini pjesën tjetër të aplikacionit të përdorshëm. Një zbulues që fsheh të gjithë ndërfaqen sa herë që nuk është i sigurt krijon një ndërprerje për këdo tuneli i të cilit përdor një emër që nuk e parashikuat kurrë. Kthehuni te sjellja konservative: veçoritë lokale vazhdojnë të funksionojnë dhe çaktivizohet vetëm thirrja në distancë që i nevojitet vërtet tunelit. Kjo zgjedhje është një vendim produkti, dhe meriton të shkruhet pranë heuristikës.
Regjistroni atë që vëzhguat: emrat e ndërfaqeve, versionin e platformës dhe rezultatin e një sonde. Kjo e kthen raportin tjetër nga debat në kontroll. Pastaj preferoni një deklaratë të mbështetur kur e keni një të tillë, sepse një konfigurim i menaxhuar mund ta mbajë qëllimin në mënyrë eksplicite dhe të heqë pjesën më të madhe të arsyes për të inspektuar emrat.
Nëse kontrollet 1 deri 5 ju lanë pa një përgjigje të mbështetur, lëshoni sondën dhe etiketoni rezultatin me ndershmëri. Një sinjal i dokumentuar i përpjekjes maksimale është një vendim produkti më i mirë se një API private që thyhet në lëshimin tjetër.