Profil VPN iOS: passwordReference, bukan kata laluan

Anda memasang profil, terowong naik, dan semuanya kelihatan selesai. Kemudian telefon but semula, on-demand mengejutkan sambungan tanpa aplikasi di latar hadapan, dan terowong enggan bermula. Profil masih ada dan kata laluan masih betul, sebab itulah kegagalan ini menghantar orang mencari di tempat yang salah. Network Extension tidak boleh membaca rahsia anda daripada profil: ia memerlukan rujukan keychain yang boleh diselesaikannya sendiri.

Panduan di bawah mengikut satu percubaan sambungan melalui penyerahan itu, daripada pertanyaan yang membina rujukan hingga but semula yang mengujinya.

Profil menyimpan pemegang, bukan rahsia

NEVPNProtocol mendedahkan passwordReference dan sharedSecretReference atas sebab tertentu. Apabila daemon memulakan terowong, ia mungkin tidak berjalan di dalam proses anda, jadi ia tidak boleh memanggil kod anda dan meminta kata laluan. Ia membaca rujukan keychain yang berterusan, menyelesaikannya dalam konteksnya sendiri dan mengambil item itu sendiri.

Anda membina rujukan itu dengan memintanya daripada keychain, iaitu permintaan berbeza daripada permintaan data:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

Serahkan objek yang dikembalikan kepada protokol, bukan data item. Dalam amalan profil merekodkan di mana rahsia itu tinggal, sebab itulah sandaran konfigurasi tidak menyalin kata laluan secara senyap ke dalam plist.

Mengapa API menjawab -50

errSecParam bermaksud permintaan atau nilai itu cacat bentuknya untuk operasi tersebut, dan itulah ralat yang paling kerap dilihat apabila permintaan rujukan dan data bercampur. Meminta data ketika kod penerima menjangka rujukan, memberikan bait mentah kepada passwordReference, atau membuat pertanyaan dengan kumpulan akses yang tidak boleh digunakan aplikasi, semuanya menghasilkannya.

Pustaka pembalut menggalakkan ini. Pembantu yang mengembalikan bait tidak boleh ditukar ganti dengan yang mengembalikan rujukan, jadi pembaikan biasanya pertanyaan lain dan bukan kata laluan lain.

Ketidakpadanan yang sama menjelaskan profil yang disimpan tanpa aduan dan kemudian gagal menyambung: yang disimpan ialah blob, bukan pemegang, dan daemon tiada apa-apa untuk diselesaikan.

Disimpan elok, gagal semasa menyambung

Penyimpanan melatih konteks aplikasi anda. Penyambungan melatih konteks daemon, dan kedua-duanya tidak mempunyai akses yang sama. Oleh itu profil boleh lulus setiap ujian dalam simulator dan gagal pada permulaan on-demand pertama.

Bentuk gejala but semula juga sama: ia berfungsi selagi aplikasi terbuka dan mati apabila sistem memulakan terowong sendiri.

Uji laluan latar belakang dengan sengaja sebelum dikeluarkan. Cetusan sambungan on-demand dengan aplikasi tertutup, kemudian baca konsol peranti bukan log aplikasi, kerana kegagalan direkodkan oleh proses yang cuba menyelesaikan rujukan. Jika konsol menunjukkan daemon menolak item, rujukan itu baik dan masalahnya ialah kebolehcapaian item.

Kebolehcapaian menentukan sama ada but semula berjaya

Item mesti boleh dibaca oleh mana-mana proses sistem yang melancarkan terowong, dan itu khalayak yang lebih luas daripada aplikasi anda semasa di latar hadapan. Kekangan itu memilih atribut kebolehcapaian untuk anda. Item yang dilindungi sehingga buka kunci pertama tersedia untuk permulaan latar belakang selepas peranti dibuka kunci sekali; item yang menuntut peranti dibuka kunci sekarang tidak.

Memilih kelas yang lebih ketat memang menggiurkan dan itulah yang memecahkan profil on-demand pada telefon berkunci.

Selepas menukar kelas, cipta semula item itu dan bukan menyunting atribut pada item sedia ada, kemudian simpan semula protokol dengan rujukan baharu. Perubahan atribut pada item sedia ada tidak selalu menghasilkan tingkah laku yang disiratkan dokumentasi, dan item yang dibina semula menghapuskan keraguan.

Putaran ialah tempat profil tersimpan mereput

Menukar kata laluan dalam keychain tidak menukar secara automatik apa yang ditunjuk oleh profil tersimpan. Memadam item lebih teruk: profil menyimpan rujukan kepada sesuatu yang tidak wujud lagi, dan kegagalan kelihatan seperti penolakan pengesahan.

Putar dalam satu urutan. Kemas kini item, pertanyaan rujukan berterusan baharu, simpan semula protokol, kemudian sambung dengan aplikasi tertutup untuk membuktikan daemon masih boleh menyelesaikannya. Simpan kata laluan pengguna dan rahsia kongsi dalam item berasingan supaya setiap satu berputar mengikut jadualnya sendiri, dan jangan sekali-kali log kamus pertanyaan atau rujukan itu sendiri. Pemegang itu bukan rahsia, tetapi ia peta kepadanya.