API iOS VPN: NEVPNManager, penyedia terowong atau profil?

Tiga produk berbeza menjawab nama iOS VPN, dan mereka tidak berkongsi satu API. Personal VPN menaiki pengangkutan IPsec dan IKEv2 terbina dalam sistem. Custom tunnel menjalankan protokol anda sendiri di dalam network extension. Configuration profile mengkonfigurasi salah satu daripadanya dan boleh menambah tingkah laku on-demand. Memilih mengikut pengangkutan yang mesti anda tuturkan lebih pantas daripada memilih mengikut tutorial yang dikompilasi dahulu.

Jalankan pemeriksaan di bawah mengikut susunan, kerana setiap langkah menganggap langkah sebelumnya menghasilkan konfigurasi yang sah.

Langkah 1: pilih mengikut pengangkutan

Jika pelayan ialah IKEv2 atau IPsec gaya Cisco, NEVPNManager sudah memadai dan pengangkutan sistem datang percuma. Jika pelayan bercakap OpenVPN, WireGuard atau apa-apa lagi, NEVPNManager tidak dapat membantu: ia tiada cangkuk untuk protokol pihak ketiga. Kes itu memerlukan NETunnelProviderManager dengan packet tunnel provider yang melaksanakan protokol itu. Profil hanya mengedarkan konfigurasi, dan ia tidak boleh menambah pengangkutan yang tiada pada sistem pengendalian.

PPTP bukan sasaran pada sistem semasa. IPsec dengan rahsia dikongsi masih menjangkakan nama kumpulan dalam remoteIdentifier, item keychain yang menyimpan rahsia itu, dan pengesahan lanjutan apabila pelayan meminta nama pengguna. Setiap bahagian yang hilang muncul sebagai ralat konfigurasi generik yang sama, jadi tambah semuanya sebelum menyahpepijat apa-apa lagi.

Langkah 2: hormati susunan simpan, muat, mula

NEVPNManager menulis ke preferences, membacanya semula, dan hanya kemudian bermula. Isi objek protokol dan manager, panggil saveToPreferences, panggil loadFromPreferences, dan panggil startVPNTunnel daripada load completion handler. Memulakan sebelum muatan kembali menghasilkan ralat configuration-invalid, NEVPNErrorDomain code 1, pada konfigurasi yang sebenarnya betul.

Bentuknya cukup pendek untuk disimpan di satu tempat:

manager.protocolConfiguration = proto
manager.isEnabled = true
manager.saveToPreferences { }
manager.loadFromPreferences { manager.connection.startVPNTunnel() }

startVPNTunnel kembali apabila permintaan diterima, bukan apabila terowong sudah naik. Perhatikan NEVPNStatusDidChange dan baca connection.status untuk keadaan sebenar. Aplikasi yang menganggap kejayaan di tempat panggilan melaporkan VPN bersambung sementara extension masih berunding. Status connecting adalah normal seketika; status yang tidak pernah keluar daripadanya ialah kegagalan yang wajar dilog.

Langkah 3: beri proses provider apa yang diperlukan

Custom transport berjalan dalam proses berasingan dengan bundle identifier sendiri dan entitlement sendiri. Aplikasi container dan provider kedua-duanya memerlukan entitlement network-extension semasa menandatangani, dan binaan Developer ID di luar App Store masih mesti membawanya dalam provisioning profile. Entitlement yang hilang kelihatan seperti pepijat protokol kerana extension langsung tidak bermula.

Tiada socket descriptor awam untuk dipinjam. NEPacketTunnelProvider memberi anda NEPacketTunnelFlow dengan read, write dan cancel, dan kod yang mencapai laluan kunci peribadi rosak antara keluaran. Provider terus berjalan semasa aplikasi di latar belakang, jadi aplikasi container tidak memerlukan mod latar belakang untuk itu.

Langkah 4: on-demand ialah set peraturan, bukan suis

isOnDemandEnabled hanya melengkapkan peraturan; NEOnDemandRuleConnect dan saudara-saudaranya menentukan bila terowong naik. Peraturan evaluate-connection dengan probe URL hanya sebaik URL itu. Jika probe menjawab tanpa terowong, peraturan menyimpulkan rangkaian peribadi sudah boleh dicapai dan tidak pernah bersambung, jadi halakan ia kepada sesuatu yang hanya menjawab dari dalam.

Always-on ialah janji berasingan. Ia memerlukan peranti yang diselia dan profil terurus, dan pengguna yang tidak diselia boleh membuang profil bila-bila masa. Jangan hantar reka bentuk yang bergantung pada always-on melainkan armada diselia.

Langkah 5: buktikan laluan, bukan label

Mengimbas antara muka tun, tap, ppp atau ipsec membuktikan bahawa VPN dikonfigurasi, bukan bahawa permintaan anda menggunakannya. NWPathMonitor dengan usesInterfaceType(.other) menyatakan antara muka maya tersedia, dan viability handler boleh menguji satu hos. Kedua-duanya tidak membuktikan laluan keluar, jadi gabungkan dengan permintaan kepada sumber yang hanya boleh dicapai oleh terowong. Nama antara muka ialah bantuan diagnostik, bukan pintu gerbang yang logik aplikasi patut bercabang.

Untuk pemeriksaan lapangan, bandingkan alamat awam dengan dan tanpa terowong dan ambil halaman dalaman sahaja. Panggilan status boleh melaporkan bersambung semasa provider berunding, jadi biarkan hasil sumber yang menentukan dan anggap status sebagai bukti sokongan.