Bagaimana aturan domain Apple VPN On Demand memicu tunnel

Tunnel terbuka saat Anda meminta satu nama internal dan tetap tertutup saat aplikasi berikutnya membutuhkannya sama mendesak. Itu bukan bug di aplikasi; itu bentuk aturan domain. Konfigurasi on-demand Apple menjelaskan syarat untuk membuat koneksi, dan bentuk domain dari syarat itu menanyakan resolver sistem sebelum satu paket pun bergerak. Dua pertanyaan terus dicampur: kapan tunnel harus naik, dan apa yang dibawa tunnel setelah ada. Yang pertama adalah pemicu, yang kedua adalah kebijakan rute dan resolver, dan satu profil biasanya menetapkan keduanya di payload yang sama, itulah sebabnya aturan domain yang benar masih bisa meninggalkan Anda di jaringan yang salah.

Pemicu dan pemilihan lalu lintas berada di lapisan berbeda

Aturan on-demand hidup di kamus on-demand sebuah payload VPN: daftar aturan berurutan, masing-masing dengan aksi dan sekumpulan syarat kecocokan. Sistem mengevaluasinya saat konektivitas berubah atau saat sesuatu mencoba mencapai jaringan, dan aksi menentukan apakah tunnel dinaikkan, dievaluasi, diputus, atau diabaikan. Semua ini terjadi di lapisan jaringan platform, sebelum aplikasi Anda memiliki socket.

Apa yang terjadi setelahnya adalah kelompok kunci terpisah: pengaturan IPv4 dan IPv6 tunnel, rute yang disertakan dan dikecualikan, alamat server DNS, dan di iOS serta iPadOS pemetaan per aplikasi yang menentukan aplikasi mana yang boleh memakai tunnel. Sebuah profil dapat memasangkan pemicu luas dengan rute sempit, atau pemicu sempit dengan rute default. Baca hanya satu bagian dan bagian lain akan tampak seperti kerusakan.

Saya punya profil laboratorium yang terhubung setiap kali sesuatu di bawah domain internal diminta tetapi hanya merutekan satu /16 ke tunnel. Ia melakukan persis apa yang dikatakan payload-nya, dan itu juga jenis profil yang menghasilkan tiket: orang menganggap tunnel yang terhubung berarti lalu lintas mereka ada di dalamnya.

Apa yang sebenarnya ditanyakan aturan domain ke resolver

Bentuk domain dari aturan, yang sering disebut connect-if-needed, tidak memeriksa payload paket atau mengawasi URL. Saat nama diresolusi, sistem membandingkannya dengan domain dalam aturan dan, jika cocok, menanyakan apakah nama itu dapat diresolusi melalui server DNS yang disediakan tunnel. Jika resolver tunnel menjawab, nama dianggap internal dan koneksi dimulai. Jika resolver lokal yang menjawab, nama diperlakukan sebagai eksternal dan tidak ada tunnel yang muncul. Ikhtisar penerapan Apple menjelaskan ini sebagai deteksi jaringan lalu evaluasi koneksi.

Dua konsekuensi mengikuti. Profil harus menyebut server DNS di dalam tunnel; aturan domain tanpa resolver tunnel tidak punya apa pun untuk dibandingkan, sehingga evaluasi tidak dapat menghasilkan kecocokan yang Anda harapkan. Dan pencarian harus mencapai resolver sistem. Aplikasi atau browser yang menjalankan DNS terenkripsi sendiri, ekstensi yang menjawab secara lokal, atau koneksi ke alamat literal tidak pernah menghasilkan resolusi nama yang ditunggu aturan. Salah satu sore terpanjang yang saya lalui berakhir ketika saya menemukan bahwa klien di depan tunnel menggunakan DNS over HTTPS.

Cache juga menghapus pemicu. Nama yang sudah ada di cache dapat dijawab tanpa probe yang seharusnya memulai tunnel, sehingga aturan yang berfungsi kemarin gagal setelah reboot, atau setelah tunnel menyala beberapa saat. Di macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder mengatur ulang keadaan; di iOS mengaktifkan dan mematikan mode pesawat atau memulai ulang perangkat memberi Anda awal yang bersih dan sebanding.

Cakupan kecocokan: nama, aplikasi, dan jaringan

Pencocokan domain adalah satu jenis di antara beberapa. Aturan juga dapat mencocokkan jenis antarmuka (Wi-Fi, seluler, Ethernet) dan SSID tertentu, dan entri per aplikasi atau domain Safari mengikat tunnel ke satu alur kerja. Ikatan itu menjelaskan pengalaman aneh ketika hanya satu aplikasi berperilaku berbeda dari yang lain: aplikasi lain berada di luar cakupan tunnel, jadi mereka tetap memakai jalur lokal bahkan saat ikon tunnel menyatakan terhubung.

Urutan lebih penting daripada yang orang duga. Aturan dievaluasi berurutan dan yang pertama cocok memberikan aksi, jadi aturan luas sambungkan-di-Wi-Fi-apa-saja yang diletakkan di atas aturan domain sempit akan menang diam-diam dan membuat aturan domain tidak dapat diuji. Sebelum menulis ulang daftar domain, pastikan tidak ada aturan sebelumnya yang sudah cocok.

Itu juga sebabnya always-on bukan sekadar aturan on-demand yang lebih ketat. Penegakan always-on adalah mode penerapan terpisah dengan persyaratan pengawasan dan pengelolaannya sendiri; ia menjaga tunnel tetap terbuka alih-alih bereaksi terhadap nama. Jika yang Anda butuhkan adalah tunnel yang tidak pernah putus, aturan domain adalah alat yang salah.

Mode kegagalan yang meniru aturan rusak

Sebagian besar laporan bahwa aturan domain tidak berfungsi jatuh ke salah satu dari lima tempat, dan hanya yang terakhir adalah teks aturannya.

Portal captive layak mendapat baris sendiri, karena Wi-Fi hotel dan bandara mencegat tepat pencarian yang menjadi sandaran aturan. Sampai portal mengizinkan perangkat, server DNS tunnel tidak terjangkau, probe gagal, dan kegagalan tampak seperti domain yang salah eja. Autentikasi adalah kasus senyap lainnya: aturan dapat terpicu, tunnel dapat mulai terhubung, dan koneksi mati pada sertifikat kedaluwarsa atau prompt yang muncul di layar lain.

IPv6 menciptakan varian yang mudah salah didiagnosis. Nama dengan kedua keluarga alamat dapat dijawab lebih dulu dari catatan AAAA, sementara daftar rute tunnel hanya membawa IPv4. Satu browser berhasil, yang lain gagal, dan daftar domain sama sekali tidak bersalah.

Uji dengan permintaan nyata, dalam urutan ini

Baca kebijakan sebelum menebak. Di macOS sudo profiles show -type configuration mencetak profil terpasang termasuk payload VPN, scutil --nc list menunjukkan status layanan, dan scutil --nc show <service> mencetak kamus on-demand yang dipakai sistem. Pada iPhone atau iPad yang dikelola, payload yang sama datang dari konsol manajemen atau laporan MDM. Log jaringan tersedia dengan log stream --predicate 'subsystem == "com.apple.networkextension"' di macOS, dan melalui konsol perangkat saat telepon terpasang.

Lalu uji dengan nama host yang belum ditanyakan sebelumnya dalam sesi. Pilih nama di zona DNS tunnel yang Anda tahu resolves secara internal, minta sekali, dan amati apakah tunnel muncul. Jalankan pencarian yang sama dua kali: percobaan kedua melatih jalur cache, dan perbedaannya memberi tahu Anda apakah pemicunya resolusi atau perutean.

Setelah tunnel naik, verifikasi kedua lapisan secara terpisah. netstat -rn -f inet dan netstat -rn -f inet6 menunjukkan ke mana setiap prefiks mengarah, scutil --dns menunjukkan urutan resolver dan antarmuka mana yang memiliki tiap resolver, dan nettop -m route menunjukkan antarmuka mana yang membawa byte. Jika tunnel naik dan resolver benar tetapi sumber daya masih gagal, berhenti menyunting aturan; periksa otorisasi sisi server dan rute kembali.

Ketika aturan itu milik orang lain

Jika tunnel muncul lagi setelah Anda memutusnya, aturan biasanya milik profil, bukan aplikasi: konfigurasi yang didorong MDM, profil pribadi yang tertinggal, atau profil yang dipasang klien lain. sudo profiles show -type configuration plus pencarian kunci on-demand akan mempersempitnya, dan jalur penghapusan adalah profilnya, bukan tombol di bilah menu. Menghapus entri layanan atau aplikasi meninggalkan aturannya, dan pemasangan berikutnya mewarisinya lagi.

Satu pengujian menyelesaikan kepemilikan: putuskan, tunggu, minta nama internal lagi. Jika tunnel kembali, pemicunya bekerja sebagaimana dirancang dan pertanyaan terbukanya adalah siapa yang mengelolanya dan apakah cakupan itu yang Anda inginkan.

Sebelum melaporkan ini sebagai bug, lalui lima pemeriksaan yang sama: alamat resolver tunnel ada di payload, nama yang tidak di-cache, tidak ada aturan sebelumnya yang sudah cocok, jalur AAAA yang dicakup daftar rute, dan aplikasi di dalam cakupan tunnel. Ketika kelimanya terpenuhi, aturan menjalankan tugasnya dan kesalahannya ada lebih jauh di sepanjang jalur.