API iOS VPN: NEVPNManager, penyedia tunnel, atau profil?

Tiga produk berbeda menjawab nama iOS VPN, dan mereka tidak berbagi API. Personal VPN memakai transport IPsec dan IKEv2 bawaan sistem. Custom tunnel menjalankan protokol Anda sendiri di dalam network extension. Configuration profile mengonfigurasi salah satunya dan dapat menambahkan perilaku on-demand. Memilih berdasarkan transport yang harus Anda ajak bicara lebih cepat daripada memilih berdasarkan tutorial mana yang lebih dulu terkompilasi.

Jalankan pemeriksaan di bawah ini secara berurutan, karena setiap langkah menganggap langkah sebelumnya menghasilkan konfigurasi yang valid.

Langkah 1: pilih berdasarkan transport

Jika server adalah IKEv2 atau IPsec gaya Cisco, NEVPNManager sudah cukup dan transport sistem datang gratis. Jika server berbicara OpenVPN, WireGuard, atau apa pun yang lain, NEVPNManager tidak dapat membantu: ia tidak punya kait untuk protokol pihak ketiga. Kasus itu membutuhkan NETunnelProviderManager dengan packet tunnel provider yang mengimplementasikan protokol tersebut. Profil hanya mendistribusikan konfigurasi, dan ia tidak dapat menambahkan transport yang tidak dimiliki sistem operasi.

PPTP bukan target pada sistem saat ini. IPsec dengan shared secret masih mengharapkan nama grup di remoteIdentifier, item keychain yang menyimpan rahasia, dan autentikasi tambahan saat server meminta nama pengguna. Setiap bagian yang hilang muncul sebagai kesalahan konfigurasi generik yang sama, jadi tambahkan semuanya sebelum men-debug hal lain.

Langkah 2: hormati urutan save, load, start

NEVPNManager menulis ke preferences, membacanya kembali, dan baru kemudian memulai. Isi objek protokol dan manager, panggil saveToPreferences, panggil loadFromPreferences, dan panggil startVPNTunnel dari load completion handler. Memulai sebelum load kembali menghasilkan kesalahan configuration-invalid, NEVPNErrorDomain code 1, pada konfigurasi yang sebenarnya benar.

Bentuknya cukup singkat untuk disimpan di satu tempat:

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

startVPNTunnel kembali saat permintaan diterima, bukan saat tunnel sudah naik. Amati NEVPNStatusDidChange dan baca connection.status untuk keadaan sebenarnya. Aplikasi yang menganggap sukses di titik pemanggilan melaporkan VPN terhubung selagi extension masih bernegosiasi. Status connecting normal untuk sesaat; status yang tidak pernah meninggalkannya adalah kegagalan yang layak dicatat.

Langkah 3: beri proses provider apa yang dibutuhkannya

Custom transport berjalan di proses terpisah dengan bundle identifier sendiri dan entitlement sendiri. Aplikasi container dan provider sama-sama memerlukan entitlement network-extension saat penandatanganan, dan build Developer ID di luar App Store tetap harus membawanya di provisioning profile. Entitlement yang hilang terlihat seperti bug protokol karena extension gagal dimulai begitu saja.

Tidak ada socket descriptor publik untuk dipinjam. NEPacketTunnelProvider memberi Anda NEPacketTunnelFlow dengan read, write, dan cancel, dan kode yang meraih jalur kunci privat rusak antar rilis. Provider tetap berjalan saat aplikasi di latar belakang, jadi aplikasi container tidak perlu mode latar belakang untuk itu.

Langkah 4: on-demand adalah kumpulan aturan, bukan sakelar

isOnDemandEnabled hanya mempersenjatai aturan; NEOnDemandRuleConnect dan saudaranya menentukan kapan tunnel naik. Aturan evaluate-connection dengan probe URL hanya sebaik URL itu. Jika probe menjawab tanpa tunnel, aturan menyimpulkan jaringan privat sudah terjangkau dan tidak pernah terhubung, jadi arahkan ke sesuatu yang hanya menjawab dari dalam.

Always-on adalah janji terpisah. Ia membutuhkan perangkat yang diawasi dan profil terkelola, dan pengguna yang tidak diawasi dapat menghapus profil kapan saja. Jangan mengirim desain yang bergantung pada always-on kecuali armadanya diawasi.

Langkah 5: buktikan jalurnya, bukan labelnya

Memindai antarmuka tun, tap, ppp, atau ipsec membuktikan bahwa VPN dikonfigurasi, bukan bahwa permintaan Anda memakainya. NWPathMonitor dengan usesInterfaceType(.other) menyatakan antarmuka virtual tersedia, dan viability handler dapat menguji satu host. Keduanya tidak membuktikan jalur keluar, jadi gabungkan dengan permintaan ke sumber daya yang hanya bisa dijangkau tunnel. Nama antarmuka adalah bantuan diagnostik, bukan gerbang tempat logika aplikasi harus bercabang.

Untuk pemeriksaan lapangan, bandingkan alamat publik dengan dan tanpa tunnel dan ambil halaman khusus internal. Panggilan status dapat melaporkan terhubung selagi provider bernegosiasi, jadi biarkan hasil sumber daya yang memutuskan dan perlakukan status sebagai bukti pendukung.