Mengesan VPN aktif dalam apl Mac ber-sandbox

Anda perlukan satu skrin berkelakuan berbeza apabila terowong aktif, dan tiada panggilan yang memberitahu anda. Itulah kekangan penghantaran: pada macOS tiada rangka kerja awam melaporkan sama ada VPN sewenang-wenangnya disambungkan, dan pada iOS status itu milik apl yang memasang konfigurasi. Semakan di bawah bergerak dari had itu ke sesuatu yang boleh anda hantar, dan mana-mana satu daripadanya boleh menamatkan carian lebih awal.

Semakan 1: bolehkah soalan ini dijawab sama sekali?

Sandbox menyelesaikan soalan itu sebelum mana-mana API. Proses pihak ketiga tidak boleh menyenaraikan sambungan vendor lain, dan tidak boleh membaca konfigurasi sambungan itu juga, jadi tiada objek yang disokong untuk ditanya.

Setiap jalan pintas melanggar dinding yang sama. Senarai antara muka, scutil --nc list dan bacaan konfigurasi sistem secara langsung sama ada memerlukan hak yang ditahan oleh sandbox atau bergantung pada tingkah laku yang Apple tidak pernah janjikan. Jika rancangan memerlukan salah satu daripadanya, masalahnya ialah rancangan itu. Ciri yang dibina atas butiran tidak berdokumen ialah tiket sokongan dengan tarikh penghantaran.

Semakan 2: adakah apl anda menguruskan terowong itu sendiri?

Jika ya, anda mempunyai jawapan yang disokong untuk konfigurasi anda sendiri. Muatkan keutamaan, kendalikan ralat, kemudian baca status dan langgan perubahan dan bukannya membuat tinjauan:

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
}

Tepat tentang apa yang dikembalikan ini: status terowong yang anda pasang. Pengguna yang menjalankan klien lain akan dipaparkan sebagai terputus, dan itu bukan pepijat dalam kod anda. Tentukan mana satu daripada dua soalan itu yang sebenarnya ditanya oleh ciri anda sebelum membina atas jawapannya.

Semakan 3: apa yang sebenarnya akan diberitahu oleh heuristik kepada anda?

Pendekatan yang banyak disalin meminta kamus proksi sistem untuk entri berlingkupnya dan membaca kuncinya, yang kebetulan merupakan nama antara muka:

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

Kunci yang bermula dengan tap, tun, ppp, ipsec atau utun membayangkan bahawa antara muka berlingkup terowong hadir. Memadankan seluruh nama gagal serta-merta, kerana iOS 12 hadir dengan utun1 dan utun2 dan sesetengah profil muncul sebagai ipsec4, ppp0 atau utun0. Bandingkan awalan sebaliknya.

Walaupun begitu, nama tidak mengenal pasti mana-mana pemilik. Ciri sistem dan sambungan vendor lain juga mencipta antara muka utun, dan satu boleh wujud tanpa membawa apa-apa trafik anda. Bacalah sebagai petunjuk bahawa ada sesuatu berbentuk terowong berdekatan, tidak lebih kuat. Positif palsu di sini murah jika anda hanya mengawal satu ciri, dan mahal jika anda mengawal skrin log masuk.

Semakan 4: bolehkah anda menguji destinasi sebagai gantinya?

Jika apl hanya perlu tahu sama ada perkhidmatan dalaman boleh dicapai, uji perkhidmatan itu. Prob pendek dengan had masa menjawab soalan yang sebenarnya menjadi asas ciri itu, dan ia terus berfungsi apabila pengguna menukar klien atau terowong berubah bentuk.

Kebolehlaksanaan ialah pemerhatian tentang laluan anda. Nama antara muka ialah kesimpulan tentang sesuatu yang bersebelahan dengan laluan anda, itulah sebabnya heuristik menghasilkan perdebatan dalam laporan pepijat dan prob menghasilkan bukti. Jika prob gagal sementara pengguna berkeras VPN aktif, kini anda mempunyai laluan konkrit untuk dinyahpepijat: penyelesaian nama, laluan atau kebenaran perkhidmatan.

Semakan 5: bolehkah platform menguatkuasakan apa yang anda perlukan?

Apabila keperluan itu ialah jaminan bahawa tiada apa yang terlepas dari terowong, profil ialah tempatnya, bukan pengesan. Mengaktifkan includeAllNetworks dalam konfigurasi terowong penuh pada iOS 14 atau lebih baru mengubah tingkah laku platform dan bukannya meminta apl anda membuat kesimpulan. Bendera itu didokumenkan dalam rujukan NEVPNProtocol.

Itu jenis jawapan yang berbeza: penguatkuasaan dan bukannya pemerhatian. Ia juga hanya terpakai kepada profil yang anda kawal, jadi ia tidak membantu apl pengguna yang memerhati terowong orang lain.

Semakan 6: jadikan kegagalan selamat dan boleh diperhatikan

Matikan hanya keupayaan yang memerlukan terowong dan biarkan seluruh apl itu boleh digunakan. Pengesan yang menyembunyikan seluruh antara muka setiap kali ia tidak pasti mencipta gangguan untuk sesiapa yang terowongnya menggunakan nama yang tidak pernah anda jangkakan. Kembali kepada tingkah laku konservatif: ciri setempat terus berfungsi dan hanya panggilan jauh yang benar-benar memerlukan terowong dilumpuhkan. Pilihan itu ialah keputusan produk, dan ia wajar ditulis di sebelah heuristik.

Log apa yang anda perhatikan: nama antara muka, versi platform dan hasil satu prob. Itu menjadikan laporan seterusnya daripada perdebatan menjadi semakan. Kemudian utamakan pengisytiharan yang disokong apabila anda memilikinya, kerana konfigurasi terurus boleh membawa niat itu secara eksplisit dan menghapuskan sebahagian besar sebab untuk memeriksa nama sama sekali.

Jika semakan 1 hingga 5 meninggalkan anda tanpa jawapan yang disokong, hantarkan prob itu dan labelkan hasilnya dengan jujur. Isyarat usaha terbaik yang didokumenkan ialah keputusan produk yang lebih baik daripada API peribadi yang rosak pada keluaran seterusnya.