Mengapa apl tidak boleh menghidupkan profil VPN tersimpan pada Android atau iOS
Membina terowong sendiri dan menghidupkan profil tersimpan ialah dua kerja berbeza. Bandingkan apa yang sebenarnya dibenarkan oleh Android, iOS dan desktop kepada apl.
Dua kerja yang sangat berbeza dikumpulkan di bawah nama VPN berprogram, dan hanya satu daripadanya tersedia kepada apl biasa pada mana-mana dua platform mudah alih. Yang pertama ialah menghidupkan profil yang telah disimpan pengguna; yang kedua ialah membina terowong dalam proses anda sendiri. Android memberikan yang kedua melalui VpnService dan iOS memberikan yang kedua melalui hak Network Extension, manakala yang pertama kekal dengan sistem, pemilik peranti atau pelayan MDM. Menentukan mana yang anda benar-benar perlukan biasanya menjadikan projek lebih kecil.
Dua kerja yang berkongsi nama
Mengaktifkan profil tersimpan bermakna memberitahu terowong sedia ada supaya naik: hos, kelayakan, protokol, semuanya sudah dikonfigurasikan di tempat yang boleh dilihat pengguna. Membina terowong bermakna kod anda memiliki antara muka, gelung paket dan protokol. Kedua-duanya kelihatan serupa dalam backlog produk dan hampir tidak berkongsi pelaksanaan.
Tiada platform mudah alih mendedahkan yang pertama kepada apl SDK. Sambungan yang muncul tanpa pengguna melakukan apa-apa tidak dapat dibezakan daripada perisian hasad, jadi kedua-dua sistem meletakkan pintu persetujuan di hadapan setiap apl yang membawa trafik.
Android: pintu persetujuan, dan tiada API profil
VpnService telah wujud sejak Android 4.0 dan membolehkan apl mencipta antara muka tun, kemudian membaca dan menulis paket. Perkhidmatan mesti diisytiharkan dengan BIND_VPN_SERVICE, dan VpnService.prepare() menghasilkan dialog sistem yang meminta pengguna membenarkannya. Contoh platform, ToyVpn, ialah pernyataan paling jelas tentang bentuk yang dimaksudkan: kod anda memiliki antara muka dan segala-galanya yang mengalir melaluinya.
Apa yang tidak dilakukannya ialah menambah entri pada skrin tetapan VPN sistem. Tiada API awam untuk itu, dan apl Tetapan menyimpan profilnya dalam stor yang tidak dapat dicapai oleh apl biasa. Panggilan kepada kelas tersembunyi daripada aplikasi biasa menghasilkan profil yang tidak pernah disenaraikan oleh sistem, sebab itulah kod yang kelihatan berfungsi dalam satu binaan secara senyap berhenti berfungsi dalam binaan seterusnya.
Laluan terurus adalah berasingan. Pemilik peranti atau pemilik profil boleh menetapkan pakej VPN yang sentiasa hidup melalui API dasar peranti, dan alat perusahaan boleh menghantar profil yang kemudiannya diluluskan oleh pengguna. Itu kuasa pengurusan peranti, bukan kebenaran yang diminta apl semasa pemasangan. Jika pelanggan anda sebuah organisasi, inilah laluan yang perlu dirancang; jika pelanggan anda seorang individu yang memasang daripada kedai, ia langsung tidak tersedia.
iOS: hak ialah sempadan
iOS membahagikan kerja yang sama secara berbeza. Klien VPN melaksanakan penyedia terowong paket atau proksi apl di bawah rangka kerja Network Extension, dan hak yang sepadan mesti diberikan kepada akaun pembangun. Konfigurasi VPN peribadi melalui NEVPNManager wujud untuk kes yang lebih mudah, dan ia masih berjalan dalam model kebenaran yang sama. Apple mendokumenkan seluruh permukaan dalam rujukan Network Extension, yang wajar dibaca sebelum anda menentukan skop kerja.
Tiada cara yang disokong untuk membuka skrin tetapan VPN, membaca konfigurasi tersimpan pengguna atau memulakan salah satunya. Apa yang boleh dilakukan oleh klien ialah menghantar profil konfigurasi untuk dipasang oleh pengguna, dan kemudian menggunakan terowong yang terhasil melalui panggilan rangkaian biasa. Terowong setiap apl ditetapkan oleh pelayan MDM melalui peraturan atas permintaan, bukan dipilih oleh apl semasa runtime.
Klien VPN daripada vendor besar bukan bukti bahawa akaun anda boleh menghantar perkara yang sama. Hak itu diminta bagi setiap akaun pembangun dan disemak, jadi risiko jadual terletak pada Apple, bukan pada pelan sprint anda.
Desktop menjangkau lebih jauh, tetapi pemilikan tidak berubah
Windows ialah kes yang permisif. Add-VpnConnection mencipta entri buku telefon daripada sesi PowerShell yang dinaikkan, dan rasdial menyambung atau memutuskannya daripada skrip. Apl juga boleh memacu klien vendor melalui baris perintahnya yang didokumenkan. Mencipta profil masih tindakan pentadbiran, kerana entri itu hidup dalam stor seluruh mesin.
macOS berkelakuan sama dengan alat yang berbeza. scutil --nc start dan stop beroperasi pada perkhidmatan yang sudah wujud, manakala mencipta satu ialah tugas pentadbiran sistem. Memiliki proses pada komputer riba tidak menjadikan anda pemilik konfigurasi.
Apa yang patut dibina sebaliknya
Jika keperluan sebenar ialah apl anda mencapai API dalaman, terowong yang sudah dijalankan oleh pengguna sudah memadai. Hantar permintaan HTTPS biasa, biarkan sistem memilih laluan, dan berhenti cuba mengawal terowong. Jika keperluannya ialah hanya trafik apl anda menggunakan terowong, minta VPN setiap apl melalui saluran pengurusan, atau tamatkan TLS di dalam apl terhadap perkhidmatan yang boleh dicapai tanpanya.
API tersembunyi bukan jalan pintas yang wajar diambil. Ia berubah antara keluaran, ia gagal semakan apl, dan kegagalan yang dihasilkannya kelihatan seperti kerosakan rangkaian biasa kepada sesiapa yang mewarisi kod itu. Perbandingan bukan Android lawan iOS; ia adalah memiliki terowong lawan meminta platform menyalurkan trafik, dan hanya yang pertama milik anda untuk dibina.