Always On VPN berbanding VPN On Demand pada iPhone: apa yang hendak dilaksanakan

Dua iPhone boleh kedua-duanya berkata VPN tetapi berkelakuan sama sekali berbeza. On Demand membuka terowong apabila satu peraturan sepadan, dan pengguna masih boleh mematikannya dalam Tetapan. Always On terurus mengekalkan liputan dikuatkuasakan pada peranti yang diselia, termasuk saat terowong tidak dapat naik. Pilih dengan bertanya apa yang mesti benar apabila pengguna tidak melakukan apa-apa, kemudian uji peralihan dan bukan keadaan mantap. Langkah di bawah mengikut urutan kegagalan pelaksanaan yang sebenar.

Langkah 1: tentukan apa yang boleh dikuatkuasakan oleh peranti

Always On ialah ciri untuk peranti yang diselia. Jika armada tidak diselia, perbincangan tamat sebelum bermula, dan tiada kunci payload menjadikan telefon tanpa penyeliaan sebagai dikuatkuasakan. Sahkan penyeliaan dari sisi pengurusan dan dari peranti, kemudian sahkan siapa yang menandatangani profil.

Pada telefon: Tetapan, kemudian Umum, kemudian VPN dan Pengurusan Peranti. Entri profil menyebut pemiliknya, dan profil peribadi yang dipasang secara manual kelihatan berbeza daripada yang dihantar oleh perkhidmatan pengurusan. Jangan simpulkan penguatkuasaan daripada nama profil atau label pemasaran pembekal; label itu bukan dasar platform.

Catat tiga fakta sebelum menyentuh konfigurasi: diselia atau tidak, profil terurus atau peribadi, dan klien mana yang membawa terowong. Setiap langkah seterusnya bergantung pada ketiga-tiganya, dan memindahkan tingkah laku daripada telefon peribadi ke profil terurus ialah cara pelaksanaan diluluskan terhadap asas yang salah.

Langkah 2: baca peraturan on-demand, bukan nama ciri

On Demand ialah senarai peraturan yang dinilai mengikut urutan. Setiap peraturan menamakan tindakan dan syarat yang memilihnya, dan syarat itulah bahagian yang menarik: jenis antara muka, SSID Wi-Fi, akhiran domain DNS atau URL siasatan. Set peraturan yang tidak pernah sepadan ialah ciri yang tidak pernah bersambung.

<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 tatasusunan dan tanya dua soalan bagi setiap peraturan: bolehkah syarat ini pernah benar pada armada ini, dan apa yang berlaku apabila tiada peraturan sepadan? Rangkaian perusahaan menukar nama titik akses, menggabungkan SSID dan menukar akhiran DNS, dan setiap suntingan itu memisahkan peraturan daripada realiti secara senyap.

Keadaan akhiran DNS paling kerap salah di lapangan, kerana akhiran yang dilaporkan telefon pada rangkaian tetamu bukan akhiran yang disediakan oleh penyelesai korporat. Sahkan nama yang benar-benar diselesaikan oleh peranti sebelum mempercayai peraturan itu.

Langkah 3: uji peralihan, bukan sambungan statik

Terowong yang naik semasa anda melihatnya membuktikan sangat sedikit. Laksanakan setiap peralihan secara sengaja dan catat apa yang dilakukan peranti, menggunakan sumber peribadi yang sama setiap kali supaya hasilnya boleh dibandingkan:

• Sertai rangkaian di mana peraturan sepatutnya sepadan, kemudian minta sumber peribadi dan sahkan ia dimuatkan.
• Tukar ke selular dengan aplikasi di latar belakang, kemudian bawa ke hadapan dan ulangi permintaan.
• Sambung ke Wi-Fi dengan portal tawanan dan lihat sama ada portal boleh dicapai atau penguatkuasaan menyekatnya sebelum anda boleh mengesahkan.
• Matikan terowong secara manual pada peranti yang diselia dan periksa sama ada ia kembali sendiri, dan berapa cepat.

Jalankan senarai yang sama pada peranti tanpa penyeliaan jika ada. Perbezaan antara kedua-dua hasil ialah tingkah laku sebenar pelaksanaan, dan itulah bahagian yang tangkapan skrin terowong bersambung tidak pernah tunjukkan.

Langkah 4: kenali dua bentuk kegagalan

Liputan yang dikuatkuasakan gagal dengan menyekat. Apabila terowong tidak dapat diwujudkan, peranti kehilangan akses internet biasa bersama sumber peribadi, dan pengguna mengalami telefon yang dalam talian tetapi tidak boleh melayari. Bersambung semula dan menyekat ialah pemerhatian berasingan, jadi log kedua-duanya dan jangan anggap ketiadaan internet sebagai satu simptom.

On Demand gagal dengan tidak mencetus. Peraturan tidak sepadan, tiada terowong muncul, dan sumber peribadi hanya tamat masa. Mudah salah mendiagnosisnya sebagai masalah pelayan, kerana klien berkelakuan tepat seperti dikonfigurasikan.

Portal tawanan terletak di antara keduanya: ia memerlukan sambungan sebelum terowong wujud, jadi dasar yang menyekat segala-galanya sehingga terowong naik memerlukan laluan terdokumentasi melalui portal. Putuskan itu dalam reka bentuk, bukan di meja bantuan.

Langkah 5: sahkan, kemudian latih pengunduran

Pengesahan berlaku pada laluan sebenar dengan trafik tidak berbahaya: minta sumber peribadi yang tidak sepatutnya awam, sahkan alamat mana yang dipersembahkan peranti ke luar, dan ulangi selepas but semula supaya anda melihat urutan permulaan dan bukan hanya keadaan hangat.

Kemudian latih penyingkiran pada peranti ujian sebelum anda memerlukannya dalam pengeluaran. Menyingkirkan profil mengembalikan peranti kepada keadaan sebelumnya, dan mengetahui berapa lama serta apa yang dilihat pengguna ialah sebahagian daripada runbook. Panduan keselamatan VPN Apple ialah rujukan tentang apa yang didokumenkan platform mengenai dasar-dasar ini, dan wajar dibaca sebelum menulis konfigurasi yang mendakwa lebih daripada platform.

Simpan tiga fakta daripada langkah pertama di sebelah set peraturan dan hasil ujian. Apabila orang seterusnya bertanya mengapa telefon bersambung pada satu rangkaian dan tidak pada rangkaian lain, nota itu menjawab dalam satu minit dan bukannya membina semula.