NEVPNManager gagal menyimpan? Urutannya ialah muat, aktifkan, simpan, sambung

Dua kod ralat menerangkan kebanyakan percubaan pertama VPN Network Extension pada iOS: NEVPNErrorDomain Code=4 dan Code=5. Kedua-duanya bukan aduan pelayan. Satu muncul apabila app menulis tetapan ke dalam objek yang tidak pernah dibaca daripada cakera, dan satu lagi apabila penulisan itu sendiri gagal, selalunya kerana profil disimpan semasa ia masih dinyahdayakan. Kedua-duanya dibetulkan dengan menukar urutan empat panggilan, bukan dengan menyentuh parameter IKEv2.

Muat dahulu, jika tidak penyimpanan tiada apa untuk dibandingkan

Pengurus menyimpan salinan profil tersimpan, dan objek yang anda edit bukan salinan itu sehingga anda membacanya. Panggil loadFromPreferences dahulu, edit di dalam pengendali penyelesaiannya, kemudian simpan. Jika anda melangkau bacaan, rangka kerja melihat ketidakpadanan antara apa yang dimilikinya dan apa yang anda tulis. Dalam Swift bentuknya sama pada setiap langkah, dan setiap langkah tergolong dalam closurenya sendiri:

let mgr = NEVPNManager.shared()
mgr.loadFromPreferences { loadErr in
    guard loadErr == nil else { return }
    let proto = NEVPNProtocolIKEv2()
    proto.serverAddress = "vpn.example.net"
    proto.username = "alice"
    proto.useExtendedAuthentication = true
    mgr.protocolConfiguration = proto
    mgr.isEnabled = true
    mgr.saveToPreferences { saveErr in
        // do not start here; reload, then connect
    }
}

Memulakan terowong dari dalam closure penyimpanan ialah kesilapan yang sama di tempat lain. Ia berjalan sebelum profil dibaca semula, jadi panggilan mula melihat keadaan yang anda bina, bukan keadaan yang disimpan. Closure penyimpanan berakhir dengan loadFromPreferences kedua, dan hanya pengendali penyelesaian itu memanggil startVPNTunnel.

Bendera pengaktifan ialah sebahagian daripada penyimpanan

Profil tersimpan tidak aktif sehingga dihidupkan. Tetapkan isEnabled = true dalam penulisan yang sama, jika tidak profil mendarat di cakera dalam keadaan dinyahdayakan dan startVPNTunnel enggan walaupun Tetapan menunjukkan konfigurasi yang kelihatan lengkap.

Suntingan luaran ialah separuh lagi. Jika pengguna menukar sesuatu dalam Tetapan, atau peranti bergerak antara rangkaian, baca semula sebelum mempercayai nilai yang masih anda pegang dalam memori. Objek tidak memerhati perubahan itu untuk anda. Salinan lapuk ialah cara app menulis profil yang senyap mengembalikan suntingan pengguna. Dua medan bersebelahan menyebabkan masalah senyap pada masa yang sama: peraturan on-demand mesti tatasusunan objek peraturan dan bukan pemegang tempat kosong, dan disconnectOnSleep harus mencerminkan tingkah laku yang anda pilih dan bukan nilai lalai yang disalin.

Hanya dua protokol tersedia untuk app pihak ketiga

Network Extension memberikan app IPsec dan IKEv2. L2TP dan PPTP kekal di dalam sistem, jadi app yang memerlukannya tidak boleh memilikinya, dan jawapan realistik ialah get laluan berkemampuan IKEv2 atau profil konfigurasi terurus.

Kelayakan mengikut corak yang sama. Letakkan kata laluan dalam Keychain dan hantar rujukan berterusan dan bukan rentetan. Rujukan nol semasa menyimpan biasanya bermaksud carian berjalan sebelum item ditulis, bukan bahawa pengurus rosak.

Kedua-duanya keputusan reka bentuk dan bukan jalan pintas. App yang menyimpan kata laluan dalam keutamaannya sendiri memilih laluan yang tidak digalakkan rangka kerja, dan kegagalan yang dihasilkannya dibaca seperti ralat penyimpanan.

Ketepikan entitlement sebelum menulis semula kod

Apabila loadFromPreferences tidak pernah memanggil balik sama sekali, punca yang mungkin ialah keupayaan Network Extension yang hilang atau profil peruntukan yang tidak membawanya. Kegagalan itu tergantung dan bukan memberi ralat, dan itulah sebabnya kod yang berfungsi ditulis semula berjam-jam. Semak entitlement pada binaan bertandatangan yang anda mahu hantar, kerana larian dalam simulator dan larian pada peranti boleh berbeza dan sasaran yang penting ialah peranti. Buka tetapan tandatangan sasaran dan sahkan keupayaan Network Extension hadir untuk binaan yang tepat itu.

Profil peruntukan tanpa entitlement gagal dengan cara yang sama pada perkakasan, manakala binaan yang sama mungkin dimuatkan seperti biasa dalam simulator. Uji arkib bertandatangan pada peranti sebenar sebelum menulis semula urutan panggilan.

Perhatikan perubahan status, bukan andaian

Perhatikan NEVPNStatusDidChangeNotification dan log manager.connection.status selepas setiap langkah. Status yang tidak pernah meninggalkan invalid bermaksud profil tidak disimpan atau entitlement tiada. Sambungan yang mencapai connecting dan tidak pernah bersambung menunjukkan cadangan atau kelayakan, yang merupakan siasatan lain dengan bukti lain.

Sahkan profil muncul di bawah Tetapan, Umum, VPN, dan catat ralat daripada setiap closure. Dua fakta itu memisahkan pepijat urutan daripada pepijat kebenaran tanpa meneka.