Always On VPN versus VPN On Demand di iPhone: apa yang harus diterapkan

Dua iPhone bisa sama-sama menyebut VPN tetapi berperilaku sangat berbeda. On Demand membuka terowongan ketika sebuah aturan cocok, dan pengguna masih dapat mematikannya di Pengaturan. Always On terkelola menjaga cakupan tetap dipaksakan pada perangkat yang diawasi, termasuk saat terowongan tidak dapat naik. Pilih dengan bertanya apa yang harus benar ketika pengguna tidak melakukan apa pun, lalu uji peralihannya, bukan keadaan mantapnya. Langkah di bawah mengikuti urutan kegagalan penerapan yang sebenarnya.

Langkah 1: tetapkan apa yang dapat dipaksakan perangkat

Always On adalah fitur untuk perangkat yang diawasi. Jika armada tidak diawasi, pembicaraan selesai sebelum dimulai, dan tidak ada kunci payload yang membuat ponsel tanpa pengawasan menjadi dipaksakan. Pastikan pengawasan dari sisi manajemen dan dari perangkat, lalu pastikan siapa yang menandatangani profil.

Di ponsel: Pengaturan, lalu Umum, lalu VPN dan Manajemen Perangkat. Entri profil menyebutkan pemiliknya, dan profil pribadi yang dipasang manual terlihat berbeda dari yang dikirim layanan manajemen. Jangan menyimpulkan pemaksaan dari nama profil atau label pemasaran penyedia; label itu bukan kebijakan platform.

Catat tiga fakta sebelum menyentuh konfigurasi: diawasi atau tidak, profil terkelola atau pribadi, dan klien mana yang membawa terowongan. Setiap langkah berikutnya bergantung pada ketiganya, dan memindahkan perilaku dari ponsel pribadi ke profil terkelola adalah cara penerapan disetujui terhadap dasar yang salah.

Langkah 2: baca aturan on-demand, bukan nama fiturnya

On Demand adalah daftar aturan yang dievaluasi berurutan. Setiap aturan menyebutkan tindakan dan kondisi yang memilihnya, dan kondisinya adalah bagian menarik: jenis antarmuka, SSID Wi-Fi, sufiks domain DNS, atau URL pemeriksaan. Kumpulan aturan yang tidak pernah cocok adalah fitur yang tidak pernah terhubung.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Baca seluruh larik dan ajukan dua pertanyaan per aturan: mungkinkah kondisi ini benar pada armada ini, dan apa yang terjadi bila tidak ada aturan yang cocok? Jaringan perusahaan mengganti nama titik akses, menggabungkan SSID, dan mengubah sufiks DNS, dan setiap perubahan itu diam-diam melepaskan aturan dari kenyataan.

Kondisi sufiks DNS paling sering salah di lapangan, karena sufiks yang dilaporkan ponsel di jaringan tamu bukan sufiks yang dilayani resolver korporat. Verifikasi nama yang benar-benar diresolusi perangkat sebelum memercayai aturan.

Langkah 3: uji peralihannya, bukan koneksi statisnya

Terowongan yang naik saat Anda melihatnya membuktikan sangat sedikit. Jalankan setiap peralihan dengan sengaja dan catat apa yang dilakukan perangkat, dengan sumber daya privat yang sama setiap kali agar hasilnya dapat dibandingkan:

• Bergabunglah ke jaringan tempat aturan seharusnya cocok, lalu minta sumber daya privat dan pastikan termuat.
• Beralih ke seluler dengan aplikasi di latar belakang, lalu bawa ke depan dan ulangi permintaannya.
• Sambungkan ke Wi-Fi dengan portal tawanan dan lihat apakah portalnya terjangkau atau pemaksaan memblokirnya sebelum Anda dapat mengautentikasi.
• Matikan terowongan secara manual pada perangkat yang diawasi dan periksa apakah ia kembali sendiri, dan seberapa cepat.

Jalankan daftar yang sama pada perangkat tanpa pengawasan jika ada. Selisih antara kedua hasil adalah perilaku nyata penerapan, dan itulah bagian yang tidak pernah ditunjukkan tangkapan layar terowongan tersambung.

Langkah 4: kenali dua bentuk kegagalan

Cakupan yang dipaksakan gagal dengan memblokir. Ketika terowongan tidak dapat terbentuk, perangkat kehilangan akses internet biasa bersama sumber daya privat, dan pengguna mengalami ponsel yang online tetapi tidak bisa menjelajah. Menyambung ulang dan memblokir adalah pengamatan terpisah, jadi catat keduanya alih-alih memperlakukan tidak adanya internet sebagai satu gejala.

On Demand gagal dengan tidak terpicu. Aturannya tidak cocok, tidak ada terowongan yang muncul, dan sumber daya privat sekadar kehabisan waktu. Mudah salah mendiagnosisnya sebagai masalah server, karena klien berperilaku persis seperti yang dikonfigurasi.

Portal tawanan berada di antara keduanya: ia membutuhkan konektivitas sebelum terowongan ada, jadi kebijakan yang memblokir semuanya sampai terowongan naik memerlukan jalur terdokumentasi melalui portal. Putuskan itu dalam desain, bukan di meja bantuan.

Langkah 5: verifikasi, lalu latih pengembalian

Verifikasi dilakukan pada jalur nyata dengan lalu lintas tak berbahaya: minta sumber daya privat yang tidak boleh publik, pastikan alamat mana yang ditampilkan perangkat ke luar, dan ulangi setelah mulai ulang agar Anda melihat urutan penyalaan, bukan hanya keadaan hangat.

Lalu latih penghapusan pada perangkat uji sebelum Anda membutuhkannya di produksi. Menghapus profil mengembalikan perangkat ke keadaan sebelumnya, dan mengetahui berapa lama serta apa yang dilihat pengguna adalah bagian dari runbook. Panduan keamanan VPN Apple adalah rujukan atas apa yang didokumentasikan platform tentang kebijakan ini, dan layak dibaca sebelum menulis konfigurasi yang mengklaim lebih dari platform.

Simpan tiga fakta dari langkah pertama di samping kumpulan aturan dan hasil uji. Ketika orang berikutnya bertanya mengapa ponsel terhubung di satu jaringan dan tidak di jaringan lain, catatan itu menjawab dalam satu menit alih-alih membangun ulang.