Bagaimana peraturan domain Apple VPN On Demand mencetuskan terowong

Terowong terbuka apabila anda meminta satu nama dalaman dan kekal tertutup apabila aplikasi seterusnya memerlukannya sama mendesak. Itu bukan pepijat dalam aplikasi; itu bentuk peraturan domain. Konfigurasi on-demand Apple menerangkan syarat untuk membuat sambungan, dan bentuk domain syarat itu bertanya kepada penyelesai sistem sebelum satu paket pun bergerak. Dua soalan sentiasa dikelirukan: bila terowong patut naik, dan apa yang dibawa terowong setelah wujud. Yang pertama ialah pencetus, yang kedua ialah dasar laluan dan penyelesai, dan satu profil biasanya menetapkan kedua-duanya dalam payload yang sama, sebab itu peraturan domain yang betul masih boleh meninggalkan anda pada rangkaian yang salah.

Pencetus dan pemilihan trafik berada pada lapisan berbeza

Peraturan on-demand tinggal dalam kamus on-demand payload VPN: senarai peraturan tersusun, setiap satu dengan tindakan dan set syarat padanan. Sistem menilainya apabila kesambungan berubah atau apabila sesuatu cuba mencapai rangkaian, dan tindakan menentukan sama ada terowong dinaikkan, dinilai, diputuskan atau diabaikan. Semua ini berlaku dalam lapisan rangkaian platform, sebelum aplikasi anda mempunyai soket.

Apa yang menyusul ialah kumpulan kunci berasingan: tetapan IPv4 dan IPv6 terowong, laluan yang disertakan dan dikecualikan, alamat pelayan DNS, dan pada iOS serta iPadOS pemetaan setiap aplikasi yang menentukan aplikasi mana boleh menggunakan terowong. Satu profil boleh memasangkan pencetus luas dengan laluan sempit, atau pencetus sempit dengan laluan lalai. Baca hanya separuh dan separuh lagi akan kelihatan seperti kerosakan.

Saya mempunyai profil makmal yang bersambung setiap kali sesuatu di bawah domain dalaman diminta tetapi hanya menghala satu /16 ke dalam terowong. Ia melakukan tepat apa yang dikatakan payloadnya, dan ia juga jenis profil yang menghasilkan tiket: orang menganggap terowong bersambung bermakna trafik mereka ada di dalamnya.

Apa yang sebenarnya ditanya peraturan domain kepada penyelesai

Bentuk domain peraturan itu, yang sering dipanggil connect-if-needed, tidak memeriksa payload paket atau memantau URL. Apabila nama diselesaikan, sistem membandingkannya dengan domain dalam peraturan dan, jika sepadan, bertanya sama ada nama itu boleh diselesaikan melalui pelayan DNS yang disediakan terowong. Jika penyelesai terowong menjawab, nama itu dikira dalaman dan sambungan dimulakan. Jika penyelesai tempatan menjawab sebaliknya, nama itu dianggap luaran dan tiada terowong muncul. Gambaran keseluruhan penggunaan Apple menerangkannya sebagai pengesanan rangkaian diikuti penilaian sambungan.

Dua akibat menyusul. Profil mesti menamakan pelayan DNS di dalam terowong; peraturan domain tanpa penyelesai terowong tidak mempunyai apa-apa untuk dibandingkan, jadi penilaian tidak boleh menghasilkan padanan yang anda jangkakan. Dan carian mesti sampai ke penyelesai sistem. Aplikasi atau pelayar yang menjalankan DNS tersulit sendiri, sambungan yang menjawab secara tempatan, atau sambungan ke alamat literal tidak pernah menghasilkan penyelesaian nama yang ditunggu peraturan. Salah satu petang terpanjang yang saya lalui berakhir apabila saya mendapati klien di hadapan terowong menggunakan DNS over HTTPS.

Cache juga menghapuskan pencetus. Nama yang sudah ada dalam cache boleh dijawab tanpa prob yang sepatutnya memulakan terowong, jadi peraturan yang berfungsi semalam gagal selepas but semula, atau selepas terowong naik beberapa lama. Pada macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder menetapkan semula keadaan; pada iOS menghidupkan dan mematikan mod pesawat atau memulakan semula peranti memberi anda permulaan bersih yang setanding.

Skop padanan: nama, aplikasi dan rangkaian

Padanan domain ialah satu jenis antara beberapa. Peraturan juga boleh sepadan dengan jenis antara muka (Wi-Fi, selular, Ethernet) dan SSID tertentu, dan entri setiap aplikasi atau domain Safari mengikat terowong kepada satu aliran kerja. Ikatan itu menjelaskan pengalaman pelik apabila hanya satu aplikasi berkelakuan berbeza daripada yang lain: aplikasi lain berada di luar skop terowong, jadi mereka terus menggunakan laluan tempatan walaupun ikon terowong menyatakan bersambung.

Susunan lebih penting daripada yang orang jangkakan. Peraturan dinilai mengikut urutan dan yang pertama sepadan memberikan tindakan, jadi peraturan luas sambung-pada-apa-apa-Wi-Fi yang diletakkan di atas peraturan domain sempit akan menang secara senyap dan menjadikan peraturan domain tidak boleh diuji. Sebelum menulis semula senarai domain, pastikan tiada peraturan terdahulu yang sudah sepadan.

Sebab itulah always-on bukan sekadar peraturan on-demand yang lebih ketat. Penguatkuasaan always-on ialah mod penggunaan berasingan dengan keperluan penyeliaan dan pengurusannya sendiri; ia mengekalkan terowong terbuka dan bukan bertindak balas kepada nama. Jika yang anda perlukan ialah terowong yang tidak pernah jatuh, peraturan domain ialah alat yang salah.

Mod kegagalan yang meniru peraturan rosak

Kebanyakan laporan bahawa peraturan domain tidak berfungsi terletak pada satu daripada lima tempat, dan hanya yang terakhir ialah teks peraturan.

Portal captive wajar mendapat barisnya sendiri, kerana Wi-Fi hotel dan lapangan terbang memintas carian yang menjadi pergantungan peraturan. Sehingga portal menerima peranti, pelayan DNS terowong tidak dapat dicapai, prob gagal, dan kegagalan kelihatan seperti domain yang salah eja. Pengesahan ialah kes senyap yang lain: peraturan boleh tercetus, terowong boleh mula bersambung, dan sambungan mati pada sijil tamat tempoh atau gesaan yang muncul pada paparan lain.

IPv6 mencipta varian yang mudah salah didiagnosis. Nama dengan kedua-dua keluarga alamat boleh dijawab dahulu daripada rekod AAAA, manakala senarai laluan terowong hanya membawa IPv4. Satu pelayar berjaya, satu lagi gagal, dan senarai domain sama sekali tidak bersalah.

Uji dengan permintaan sebenar, dalam susunan ini

Baca dasar sebelum meneka. Pada macOS sudo profiles show -type configuration mencetak profil terpasang termasuk payload VPN, scutil --nc list menunjukkan status perkhidmatan, dan scutil --nc show <service> mencetak kamus on-demand yang digunakan sistem. Pada iPhone atau iPad yang diurus, payload yang sama datang dari konsol pengurusan atau laporan MDM. Log rangkaian tersedia dengan log stream --predicate 'subsystem == "com.apple.networkextension"' pada macOS, dan melalui konsol peranti apabila telefon disambungkan.

Kemudian uji dengan nama hos yang belum ditanya lebih awal dalam sesi. Pilih nama dalam zon DNS terowong yang anda tahu diselesaikan secara dalaman, minta sekali, dan perhatikan sama ada terowong muncul. Jalankan carian yang sama dua kali: percubaan kedua melatih laluan cache, dan perbezaan antara kedua-duanya memberitahu anda sama ada pencetusnya penyelesaian atau penghalaan.

Setelah terowong naik, sahkan kedua-dua lapisan secara berasingan. netstat -rn -f inet dan netstat -rn -f inet6 menunjukkan ke mana setiap awalan menghala, scutil --dns menunjukkan susunan penyelesai dan antara muka mana yang memiliki setiap penyelesai, dan nettop -m route menunjukkan antara muka mana yang membawa bait. Jika terowong naik dan penyelesai betul tetapi sumber masih gagal, berhenti menyunting peraturan; semak kebenaran sebelah pelayan dan laluan balik.

Apabila peraturan itu milik orang lain

Jika terowong muncul semula selepas anda memutuskannya, peraturan biasanya milik profil dan bukan aplikasi: konfigurasi yang ditolak melalui MDM, profil peribadi yang tertinggal, atau profil yang dipasang oleh klien lain. sudo profiles show -type configuration serta carian kunci on-demand akan menyempitkannya, dan laluan pembuangan ialah profil, bukan togol dalam bar menu. Memadam entri perkhidmatan atau aplikasi meninggalkan peraturan itu, dan pemasangan seterusnya mewarisinya semula.

Satu ujian menyelesaikan pemilikan: putuskan, tunggu, minta nama dalaman sekali lagi. Jika terowong kembali, pencetus berfungsi seperti direka dan soalan terbuka ialah siapa yang mengurusnya dan sama ada skop itu yang anda mahukan.

Sebelum melaporkan ini sebagai pepijat, lalui lima pemeriksaan yang sama: alamat penyelesai terowong ada dalam payload, nama yang tidak di-cache, tiada peraturan terdahulu yang sudah sepadan, laluan AAAA yang diliputi senarai laluan, dan aplikasi dalam skop terowong. Apabila kelima-lima berlaku, peraturan menjalankan tugasnya dan kesalahan itu lebih jauh di sepanjang laluan.