VPN per aplikasi pada aplikasi iPhone terkelola: apa yang dirutekan dan apa yang tidak
Tunnel per aplikasi mengikuti aplikasi terkelola, bukan ponsel. Periksa asosiasi payload, salinan terkelola, aturan sesuai permintaan, dan aliran yang keluar dari aplikasi.
VPN per aplikasi di iPhone bukan sakelar untuk seluruh ponsel. Ini asosiasi antara satu aplikasi terkelola dan satu payload VPN, dibuat saat aplikasi diterapkan, dan lalu lintas semua hal lain mempertahankan rute yang sudah ada. Itulah sebabnya ponsel yang sama berperilaku tidak konsisten: aplikasi kerja membuka halaman privat sementara Safari tidak dapat menjangkau host yang sama, atau tunnel tidak pernah naik dan aplikasi melaporkan batas waktu yang tampak seperti kredensial salah. Pemeriksaan berjalan dari penyebab terluas ke bawah, jadi berhenti pada yang pertama gagal.
Periksa payload dan catatan aplikasi terlebih dahulu
Asosiasi hidup di dua objek, bukan satu. Payload VPN mendefinisikan tunnel: jenis, server, autentikasi, DNS, dan pengenal bundel penyedia saat klien khusus dipakai. Catatan aplikasi menunjuk ke payload itu, dan sebagian besar konsol manajemen menawarkannya sebagai opsi per aplikasi pada konfigurasi aplikasi, dengan nama mendekati Per-App VPN. Payload yang tidak ditunjuk aplikasi mana pun tidak merutekan apa pun per aplikasi; ia berperilaku seperti tunnel biasa yang harus dimulai seseorang secara manual.
Baca kedua objek sebelum menyentuh ponsel. Pastikan konfigurasi aplikasi merujuk payload yang Anda uji dan bukan salinan lama, karena payload duplikat dengan nama hampir sama umum setelah migrasi dan aplikasi akan dengan senang menunjuk ke yang sudah ditarik. Lalu pastikan konfigurasi mencapai perangkat: Pengaturan, Umum, VPN & Manajemen Perangkat harus menampilkannya sebagai profil terpasang. Daftar VPN di sana bukan ujiannya. Layanan per aplikasi biasanya tidak punya sakelar manual, jadi konfigurasi yang diterapkan dengan benar mungkin tidak pernah muncul di antara VPN yang bisa dijalankan. Ketiadaannya terlihat pada catatan aplikasi dan pada apakah tunnel naik saat permintaan pertama aplikasi.
Satu kondisi menjelaskan banyak tiket: model ini membutuhkan aplikasi datang melalui manajemen. Salinan yang dipasang samping atau dibeli pribadi tidak mendapatkan asosiasi, meski pengenal bundelnya cocok. Panduan penerapan VPN Apple menjelaskan model payload di baliknya (support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web).
Pastikan aplikasi terpasang adalah salinan terkelola
Asosiasi mengikuti aplikasi terpasang yang terkelola. Jika seseorang memasangnya ulang dari App Store dengan Apple ID pribadi, menggantinya dengan build perusahaan yang ditandatangani ulang, atau perangkat didaftarkan ulang dan aplikasi kembali lewat kanal lain, tunnel bisa tetap mati sementara aplikasi tampak normal.
Uji dengan perbandingan, bukan satu pengamatan. Di inventaris manajemen, aplikasi harus tampil sebagai terkelola untuk perangkat itu dengan pemetaan VPN pada catatannya. Di ponsel, tunnel harus naik saat aplikasi diluncurkan dan permintaan pertamanya keluar, bukan hanya saat seseorang memulai konfigurasi manual terpisah di Pengaturan. Jika meluncurkan aplikasi tidak mengubah apa pun dan konfigurasi manual itu berubah, aplikasi sama sekali tidak terikat ke tunnel per aplikasi.
Pembaruan penting: yang didorong lewat manajemen mempertahankan pemetaan, sedangkan pemasangan ulang yang dimulai pengguna bisa kehilangannya. Saat keluhan bertanggal dari pembaruan, periksa catatan aplikasi sebelum jaringan.
Periksa apa yang boleh diambil tunnel
Tunnel per aplikasi dipilih berdasarkan aplikasi sumber, jadi rute bawaan ponsel tetap milik Wi-Fi atau seluler. OverridePrimary adalah kunci yang mengubahnya. Saat profil menyetelnya, tunnel berperilaku seperti tunnel penuh dan setiap aplikasi mewarisinya, sehingga semua yang lewat VPN menjadi soal profil, bukan kegagalan aplikasi.
Aturan sesuai permintaan menentukan ketahanan. OnDemandEnabled plus set aturannya membuat tunnel kembali saat aplikasi mengirim lalu lintas, bertahan saat berpindah dari Wi-Fi ke seluler, atau turun begitu aplikasi masuk latar belakang. Penerapan yang tersambung lalu mati diam-diam biasanya punya aturan yang hanya cocok dengan probe yang tidak pernah aktif saat aplikasi diam.
Lalu baca sisi rute dengan jujur. Jika profil penyedia atau vendor menyediakan daftar sertakan, tunnel yang hanya membawa 10.20.0.0/16 tidak akan membawa layanan di 10.30.0.0/16; itu daftar yang menjalankan tugasnya, bukan kegagalan per aplikasi. Payload iOS bawaan tidak punya daftar sertakan. Tanpanya, pembagian mengikuti default penyedia dan IncludeAllNetworks, bukan daftar tersembunyi.
Uji aplikasinya, lalu uji apa yang keluar darinya
Uji dengan nama, bukan hanya alamat. Menyelesaikan host internal di dalam aplikasi terkelola membuktikan DNS juga melewati tunnel, karena payload menentukan resolver mana yang menjawab dan domain pencarian mana yang berlaku. Perutean bisa sempurna sementara pencarian nama gagal, dan kedua gejala menunjuk ke pengaturan berbeda.
Lalu uji batas dari kedua sisi. Aplikasi pribadi atau Safari harus mencapai halaman publik biasa dan melaporkan alamat operator atau rumah, sementara aplikasi terkelola mencapai layanan privat. Jika keduanya melaporkan alamat publik yang sama, tunnel tidak lagi per aplikasi, apa pun yang diklaim catatan aplikasi.
Aliran yang keluar dari aplikasi menghasilkan tiket yang membingungkan. Tautan yang terbuka di Safari, dokumen yang diteruskan lewat lembar berbagi, atau login SSO yang beralih ke peramban meninggalkan proses aplikasi dan tunnel bersamanya. Login yang ditampilkan di dalam aplikasi biasanya diatribusikan ke aplikasi, jadi login tertanam bisa berhasil di tempat URL yang sama gagal di Safari; verifikasi itu alih-alih menganggapnya. Saat penyedia identitas hanya dapat dijangkau lewat tunnel, pertahankan login di dalam aplikasi atau tambahkan domain penyedia ke domain Safari payload agar lalu lintas Safari yang cocok tertangkap.
Cocokkan gejala dengan lapisan
Bentuk kegagalan memberi tahu pemeriksaan mana yang harus diulang.
| What you see | Where the repair is |
|---|---|
| Tunnel never appears when the app opens | App-to-payload association, or the app is not the managed copy |
| Tunnel connects, internal name resolves, connection times out | Provider or vendor include list missing the subnet, or a far-side firewall |
| Tunnel connects, internal name fails to resolve | DNS servers or search domains in the payload |
| Every app uses the tunnel | OverridePrimary set, or a full-tunnel payload reused |
| Worked until an update, broken since | Association lost on reinstall, or the payload was replaced |
Di balik baris tengah ada dua detail: tunnel per aplikasi bisa sehat dan tetap melewatkan subnet yang tidak dicakup daftar penyedia mana pun, dan ponsel terkelola bisa menyimpan lebih dari satu konfigurasi VPN, jadi pastikan mana yang terikat ke aplikasi alih-alih menganggap itu yang Anda baca.
Perbaiki dalam urutan ini: perbaiki catatan aplikasi agar merujuk payload aktif, pasang ulang aplikasi lewat manajemen, pastikan tunnel naik pada permintaan pertama aplikasi, lalu ulangi uji nama dan batas. Jika permintaan pertama sama sekali tidak dapat memulai tunnel, berhenti dan periksa sisi penyedia, karena klien khusus membutuhkan Network Extension yang ada dan pengenalnya cocok dengan aplikasi terpasang.
Kembalikan tiga fakta alih-alih tangkapan layar: payload mana yang dirujuk catatan aplikasi, apakah Pengaturan menampilkannya sebagai profil terpasang, dan apa permintaan yang gagal, sebuah nama, alamat, atau pengalihan ke peramban. Tiga jawaban itu memisahkan kesalahan penerapan dari kesalahan perutean, dan orang berikutnya dapat bertindak tanpa mengulang diagnosis.