WireGuard DNS di iPhone: domain hanyalah akhiran pencarian

Anda menulis satu baris dengan alamat resolver dan domain perusahaan, berharap hanya nama di domain itu yang memakai resolver tunnel. Pada klien Apple, semua nama kini pergi ke sana, dan nama pendek di domain itu juga diresolusi. Baris itu melakukan dua hal terpisah, dan hanya satu di antaranya soal kueri mana yang ditangani tunnel. Yang lain adalah kemudahan mengetik yang dinaikkan menjadi kebijakan oleh bacaan yang berharap.

Apa saja yang diurai dari baris DNS

Klien membaca entri sebagai daftar dan mengklasifikasikan tiap item menurut bentuknya. Apa pun yang tampak seperti alamat menjadi server DNS; apa pun yang tampak seperti domain menjadi akhiran pencarian. Keduanya berakhir di pengaturan tunnel, tetapi di kolom berbeda. Baris ilustratif untuk tunnel yang membawa resolver privat dan satu domain internal tampak seperti ini.

DNS = 10.24.8.53, lab.internal.example

Alamat menyediakan resolver. Domain menyediakan akhiran yang memungkinkan klien mengetik nama pendek dan sistem menambahkan sisanya sebelum bertanya. Keduanya tidak mengatakan apa pun tentang membatasi resolver ke domain itu, dan itulah bagian yang orang harapkan tetapi tidak dapatkan. Hanya satu kolom di platform yang dapat menyatakan batasan itu, dan bukan kolom ini.

Dua kolom Apple, dua tugas berbeda

Apple memaparkan perbedaan itu di objek pengaturan DNS-nya. Daftar domain pencarian didokumentasikan sebagai daftar yang dipakai untuk mengkualifikasi nama host berlabel tunggal: ketik nama host telanjang dan sistem dapat menambahkan setiap akhiran bergiliran. Itu aturan pelengkapan, bukan aturan perutean. Tidak ada apa pun di daftar itu yang menentukan server mana yang ditanya.

Daftar domain pencocokan adalah properti lain. Itu menentukan ruang nama mana yang memakai kumpulan pengaturan DNS ini, dan entri kosong berarti domain bawaan, bukan satu akhiran tertentu. generator pengaturan tunnel paket di klien Apple mengikuti model itu. Ia menaruh akhiran pencarian yang diurai ke daftar pencarian, dan bila ada server, menetapkan daftar pencocokan ke string kosong. Hasilnya adalah resolver tunnel yang menjawab semua yang dikirim sistem kepadanya, plus akhiran yang membantu nama pendek.

Jadi domain di baris itu bukan pemilih ruang nama. Menambahkan yang lain tidak mempersempit kueri yang dipakai tunnel, dan menghapusnya juga tidak memperluasnya. Satu-satunya yang berubah adalah berapa banyak nama pendek yang dilengkapi.

Mengapa setiap nama tetap mencapai resolver tunnel

Dengan entri pencocokan kosong, tunnel adalah resolver kandidat untuk nama biasa, bukan hanya untuk domain perusahaan. Pada konfigurasi tunnel penuh ini biasanya tidak banyak berpengaruh, karena semua lalu lintas memang di dalam tunnel. Pada tunnel terpisah ini sangat berpengaruh. Nama publik sekarang dapat diresolusi oleh resolver yang hanya menyimpan zona privat, dan kegagalan tampak seperti VPN rusak padahal sebenarnya resolver yang hanya menjawab sebagian ruang nama. Tunnel-nya baik-baik saja, kueri keluar, dan jawaban kembali kosong.

Ada dua perbaikan dan keduanya keputusan berbeda. Jadikan resolver tunnel resolver lengkap yang meneruskan nama publik melalui jalur yang disetujui, atau berhenti mengirim nama publik ke sana dengan mengubah konfigurasi klien alih-alih daftar domain. Yang pertama menahan setiap kueri di tunnel dan memercayai hulu. Yang kedua menahan sebagian kueri secara lokal dan menerima bahwa nama privat bisa berhenti diresolusi selama tunnel mati.

Apa yang sebenarnya dibutuhkan DNS terpisah

Kebijakan resolver yang dibatasi ruang nama memerlukan klien yang memungkinkan Anda menyatakannya: cocokkan domain di platform Apple, atau pengaturan setara di produk yang Anda pakai. Kolom konfigurasi yang hanya menerima server dan akhiran tidak dapat menyatakannya, bagaimana pun tanda bacanya. Profil dapat membawa kebijakan itu karena ia menjelaskan konfigurasi terkelola, bukan petunjuk saat koneksi. Ia dapat menyebut domain, server, dan apa yang harus terjadi bila domain itu tidak terjangkau. Itulah perbedaan antara pengaturan dan kontrak.

Pada perangkat Apple terkelola, ini biasanya dikirim melalui profil konfigurasi yang membawa pengaturan DNS khusus domain. Itu mekanisme berbeda dari berkas konfigurasi WireGuard, dan keduanya hanya dapat hidup berdampingan jika klien menghormati profil. Periksa apa yang sebenarnya disebut klien Anda untuk kolom itu sebelum menganggap kedua produk berperilaku sama. Skrip wg-quick di Mac dan aplikasi WireGuard di iPhone membaca baris serupa dan memasangnya melalui lapisan berbeda.

Baca pengaturan yang terpasang, bukan konfigurasinya

Di Mac Anda dapat memeriksa hasil akhir sistem, yang lebih informatif daripada membaca ulang berkas yang Anda tulis. Daftar resolver menunjukkan server mana yang dikonfigurasi untuk domain mana, dan kueri terbatas menunjukkan mana yang menang. Klien yang merusak baris itu menunjukkannya di sini, bukan di berkas yang Anda tulis. Di iOS tidak ada baris perintah yang setara, jadi buktinya adalah hasil: nama privat yang diresolusi lewat tunnel, dan nama publik yang jawabannya mengungkap resolver mana yang menjawab.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Kedua perintah ini mencetak konfigurasi resolver saat ini dan server DNS untuk layanan aktif. Jika resolver tunnel muncul sebagai resolver bawaan tanpa batasan domain, konfigurasinya melakukan persis apa yang diminta klien. Perbaiki itu dengan mengubah mekanismenya, bukan dengan menambahkan akhiran kedua dan berharap perilakunya berubah.