Profil VPN tidak dapat diimpor di macOS: baca payload-nya dulu

Ketika sebuah profil terpasang bersih di satu Mac dan ditolak di Mac lain, jaringan belum pernah tersentuh, jadi sertifikat, gateway, dan kata sandi tidak layak disalahkan. Penginstal berhenti pada payload yang tidak mau diterimanya, dan biasanya mencatat yang mana. Hal ini menyisakan berkas profil dan apa pun yang membuatnya sebagai satu-satunya tempat kerja yang masuk akal, dan membuat penghapusan pengaturan di klien menjadi cara menghancurkan bukti, bukan perbaikan.

Baca profilnya, jangan mengatur ulang Mac

Ekspor .mobileconfig dan lihat apa yang sebenarnya dibawanya sebelum menyentuh klien:

plutil -p profile.mobileconfig | head -60

Profil VPN sebenarnya adalah dua payload dengan tugas berbeda: com.apple.vpn.managed memuat koneksi, dan com.apple.dnsSettings.managed memuat konfigurasi resolver. Instalasi berhenti pada payload pertama yang ditolak penginstal, dan penolakan itu masuk ke log sistem dengan nama payload tersebut, jadi log-lah yang memberi tahu bagian mana yang harus dibuka. Simpan salinan profil terakhir yang berhasil diimpor, karena berkas itu adalah basis pembanding selisih Anda.

Apa yang diam-diam ditambahkan generator

Apple Configurator 2.15 build 7A23 mengeluarkan blok berikut di dalam payload DNS-nya:

<key>DNS</key>
<dict>
  <key>SupplementalMatchDomainsNoSearch</key>
  <integer>0</integer>
</dict>

Di macOS 12.1, profil yang ditulis build itu ditolak saat impor. Koneksi yang dibuat dengan Configurator 2.11.1 masuk tanpa keluhan, karena rilis itu sama sekali tidak menulis kuncinya. Hapus seluruh kamus DNS atau hanya kunci yang bermasalah, simpan lagi, lalu coba lagi di mesin yang sama sebelum mengubah hal lain. Biasanya satu suntingan itu adalah seluruh perbaikannya.

Alat ini punya jebakan yang perlu diketahui sebelum Anda memercayainya. Setelah kuncinya dihapus, menyimpan koneksi yang sama tidak mengembalikannya, dan kunci itu hanya muncul lagi ketika koneksi dibuat dari awal. Perlakukan setiap profil yang baru dibuat sebagai mencurigakan dan periksa, terutama ketika seluruh rangkaian koneksi dibuat dalam satu sesi.

Jalur MDM gagal di tempat lain

Layanan manajemen yang mendorong profil yang sama bisa gagal di titik lain: klien mengeluh bahwa tidak ada layanan VPN yang dibuat sama sekali. Dalam kasus yang dilaporkan, payload yang dikonfigurasi untuk autentikasi sertifikat tetap menuntut kolom kata sandi; mengisinya dengan placeholder membuat profil dapat diterapkan, dan tidak ada yang pernah memakai nilai itu untuk mengautentikasi.

Jika Anda menempuh jalur itu, simpan string palsu dan jangan pernah kredensial sungguhan, serta jauhkan rahasia sebenarnya dari badan profil. Profil yang membawa kata sandi yang berfungsi menjadi berkas yang harus dilindungi seperti kunci, dan itu masalah yang jauh lebih besar daripada impor gagal yang Anda mulai. Putuskan siapa pemilik placeholder itu sebelum profil didistribusikan, agar nanti tidak ada yang salah menganggapnya nilai yang layak dirotasi. Mendokumentasikan alasannya ada hanya butuh satu baris dan menghemat perdebatan enam bulan kemudian.

Pastikan profilnya benar-benar mendarat

Impor yang berhasil bukan berarti layanan yang berfungsi, jadi periksa dengan urutan ini:

profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20

Perintah pertama mendaftar payload yang terpasang; yang kedua menyatakan apakah ada layanan VPN sama sekali. Yang terakhir, dijalankan setelah terhubung, menunjukkan resolver yang benar-benar akan dipakai sistem. Bacalah dengan urutan itu dan berhentilah di titik rantainya putus, karena layanan yang hilang membuat pertanyaan apa pun tentang resolver menjadi tak berarti. Sebuah profil bisa terdaftar sebagai terpasang dan tetap tidak memiliki apa pun yang bisa dipakai, dan itulah tepatnya keadaan yang dirancang untuk diungkap oleh urutan ini.

Jika terowongan muncul sementara entri layanan masih belum punya nama yang bisa dipakai, kolom nama tampilan hilang saat ekspor, dan obatnya adalah profil yang dibuat ulang, bukan penggantian nama di klien. Jika resolver terus menunjuk ke yang lokal, payload DNS dihapus lebih menyeluruh daripada yang Anda maksudkan.

Luncurkan secara bertahap, satu Mac setiap kali

Pasang di satu Mac terkelola yang menjalankan build OS yang sama, lalu periksa tiga hal secara terpisah: layanan muncul, resolver berubah, dan satu permintaan internal nyata berhasil. Baru setelah ketiganya cakupannya boleh diperluas.

Itu tiga hasil berbeda yang gagal dengan tiga cara berbeda, dan itulah yang membuat satu mesin uji layak menghabiskan sepuluh menitnya. Profil yang dapat diimpor bukan profil yang berfungsi, dan mesin tahap pertama menangkap kedua jenis kegagalan sebelum armada lainnya melihat salah satunya.