Cara memeriksa penyelesai DNS yang digunakan Mac anda pada VPN

scutil --dns mencetak konfigurasi penyelesai yang benar-benar dirujuk macOS, bukan satu pelayan DNS yang anda taip dalam panel tetapan. Outputnya lebih panjang daripada jangkaan kebanyakan orang, kerana sistem menyimpan blok penyelesai berasingan untuk laluan lalai, untuk antara muka berskop dan untuk pemajuan khusus domain. Blok di bahagian atas output bukan semestinya blok yang menjawab pertanyaan itu. Jika nama peribadi diselesaikan di pejabat dan gagal pada saat VPN naik, ketidakpadanan itu ada pada peraturan pemadanan dan laluan, bukan pada alamat pelayan. Baca susunannya dahulu, kemudian buktikan jawapannya dengan carian sebenar.

Baca susunan blok sebelum alamat

Setiap entri dibuka dengan resolver #N dan menyenaraikan nameserver[0], kadang-kadang if_index, baris flags, reach dan, apabila blok itu bukan lalai biasa, domain serta senarai search domain. Penyelesai nombor 1 tanpa domain ialah lalai yang mengendalikan nama awam. Apa-apa yang membawa Scoped dalam bendera terikat pada antara muka yang dinamakan oleh if_index, dan apa-apa yang ditanda Supplemental hanya terpakai pada domain yang disenaraikan di bawahnya.

Pemilihan ialah pemadanan akhiran. Untuk nama seperti intranet.corp.example, macOS mengutamakan penyelesai yang entri domain-nya ialah akhiran padan terpanjang, jadi blok dengan domain : corp.example mengalahkan lalai walaupun ia terletak jauh di bawah dalam output. order memutuskan seri antara domain yang sama panjang. Pandangan pertama jarang memerlukan lebih daripada ini: keseluruhan output apabila anda mahu membaca satu blok dari awal hingga akhir, baris pembuka untuk mempelajari susunan blok, dan satu laluan bertapis yang mencetak tajuk blok di sebelah baris medan. Blok berskop muncul di bawah tajuknya sendiri dan terbaca seperti sambungan senarai di atasnya, jadi kekalkan tajuk dalam pandangan setiap kali anda memetik output.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Padankan if_index dengan antara muka terowong

Indeks hanya berguna jika anda boleh menamakan antara muka di belakangnya. scutil --nwi menyenaraikan maklumat rangkaian yang dipegang sistem, termasuk antara muka utama dan kebolehsampaian, manakala ifconfig -l memberi anda nama-namanya, di mana utun0 hingga utun9 ialah calon terowong yang biasanya dicipta oleh klien. Apple menggunakan scutil --dns sebagai contoh pemeriksaannya sendiri dalam panduan penggunaan, dan mendokumenkan cara Network Extension boleh menghalakan domain terpilih ke penyelesai terpilih, iaitu mekanisme yang didedahkan oleh blok berskop itu.

Pemeriksaan yang menyelesaikan persoalan ialah sama ada penyelesai itu berada di laluan yang dipasang oleh terowong:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Jika route -n get memulangkan get laluan dan antara muka yang tidak sepadan dengan entri penyelesai, alamatnya boleh jadi betul sepenuhnya namun masih tidak dapat dicapai. Terowong terbelah yang hanya membawa subrangkaian korporat menggugurkan pertanyaan yang ditujukan kepada pelayan DNS di luarnya, dan kegagalan itu muncul sebagai tamat masa, itulah sebabnya output konfigurasi masih kelihatan bersih.

Tanya penyelesai sistem, kemudian pelayan

Tiga alat menjawab tiga soalan berbeza, dan mencampuradukkannya menghasilkan sebahagian besar kesimpulan salah dalam bidang ini. dscacheutil -q host -a name melalui penyelesai sistem yang sama seperti yang digunakan aplikasi biasa, jadi blok berskop dan tambahan terpakai. dig tanpa argumen pelayan membaca /etc/resolv.conf, yang bukan sumber kebenaran untuk penyelesaian berskop pada macOS, dan ia melangkau peraturan setiap domain sepenuhnya. dig @address mencapai tepat satu pelayan dan tidak memberitahu apa-apa tentang pemilihan.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Apabila arahan pertama menjawab dan yang kedua memulangkan NXDOMAIN, anda telah menemui pemisahan yang anda cari dan tiada apa yang rosak. Apabila yang pertama tamat masa sementara dig @10.20.0.53 menjawab, penyelesai berfungsi tetapi tidak dapat dicapai pada laluan yang dipilih oleh terowong, jadi langkah seterusnya ialah route -n get dan bukan mengubah tetapan DNS. Jauhkan nama peribadi daripada apa-apa yang anda tampal dalam tiket atau nota kongsi.

Apa yang output tidak dapat tunjukkan kepada anda

Beberapa lapisan duduk di atas atau di sebelah senarai penyelesai, dan setiap satu boleh menghantar pertanyaan ke tempat yang tidak pernah disebut oleh output. Pelayar dengan DNS selamat diaktifkan mungkin menyelesaikan melalui saluran tersulitnya sendiri, jadi halaman yang dimuatkan sementara dscacheutil tamat masa bukan percanggahan. Proksi DNS yang dipasang oleh perisian keselamatan berjalan sebagai penyedia Network Extension dan memajukan pertanyaan itu sendiri, dan scutil --dns menunjukkan apa yang dikonfigurasikan, bukan alamat huluan yang akhirnya digunakan oleh proksi itu. Domain carian menambah kedutan ketiga: nama tidak layak mendapat setiap akhiran tersenarai ditambah mengikut urutan, jadi blok yang menjawab mungkin blok yang tidak pernah anda syaki.

Jawapan basi ialah perkara termurah untuk disingkirkan dan paling kerap terlepas pandang:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Jika output berubah selepas pembersihan, keadaan itu telah dicache dan output terdahulu menggambarkan terowong yang tidak lagi wujud. Jika ia tidak berubah, konfigurasinya memang begitu, dan soalannya beralih kepada laluan dan kepada dasar aplikasi.

Buku panduan ringkas untuk sebelum dan selepas

Ambil garis dasar hanya di tempat dasar membenarkannya, dan simpan fail di luar mana-mana folder yang disegerakkan. Urutan di bawah ialah yang saya jalankan pada mesin klien: ambil garis dasar, sambung, ambil sekali lagi, kemudian bandingkan dan cari.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Baca perbezaan mengikut blok, bukan mengikut baris. Penyelesai berskop baharu yang membawa indeks antara muka terowong dan entri domain untuk akhiran peribadi ialah bentuk yang dijangka. Penyelesai lalai baharu yang menunjuk ke alamat awam ialah penemuan yang wajar dikemukakan kepada pemilik profil klien. Kemudian ulangi carian di dalam aplikasi yang benar-benar gagal, bukan hanya dalam shell, dan catat antara muka daripada route -n get di sebelah hasilnya.

Untuk membatalkan perubahan, putuskan sambungan dan ulangi pengambilan garis dasar. Jika blok berskop hilang, klien telah membersihkan dirinya. Jika blok itu masih tersenarai terhadap antara muka yang tidak lagi wujud, keadaannya sudah basi, dan pembersihan serta penyambungan semula ialah pembaikan paling lembut sebelum sesiapa menyentuh profil itu.

Empat pemeriksaan mengikut urutan ini: adakah mana-mana blok penyelesai sepadan dengan akhiran terpanjang nama itu; adakah blok itu terikat pada antara muka yang dipasang terowong; adakah laluan ke pelayan namanya menggunakan terowong; dan adakah penyelesai sistem, bukan dig, memulangkan jawapannya. Pemeriksaan pertama yang gagal memberitahu anda sama ada perlu menukar dasar DNS, laluan terowong atau aplikasi. Jika keempat-empatnya lulus dan nama itu masih gagal, masalahnya berada di atas DNS, dan perkara seterusnya yang perlu diperiksa ialah apa-apa yang menjawab port 53 di hadapannya.