DNS VPN mengambil setiap carian: betulkan dns-priority dalam NetworkManager

Sambungkan VPN pejabat dan tiba-tiba setiap carian nama pergi ke resolver korporat. Nama awam masih diselesaikan, jadi tiada apa yang kelihatan rosak sehingga nama pencetak setempat gagal atau rekod split-horizon memulangkan alamat pejabat. Pada sesetengah pemasangan Fedora yang berlaku ialah sebaliknya: resolver penyedia terus menjawab selepas terowong naik. Kedua-duanya satu soalan — resolver mana yang memiliki pertanyaan ini — dan pada sistem NetworkManager jawapannya hidup dalam sifat DNS setiap sambungan.

Dua sambungan, satu resolver pemenang

Setiap sambungan mengisytiharkan keutamaan DNS. Sambungan biasa secara lalai ialah 50 dan sambungan VPN ialah 0, dan nilai yang lebih rendah menang. Lalai itulah sebabnya sambungan VPN senyap mengatasi pautan berwayar bagi setiap domain yang dituntutnya: sifar mengalahkan lima puluh tanpa sesiapa memilihnya.

Keutamaan menyusun calon. Ia tidak mengehadkan apa yang ditanya kepada pemenang. Sambungan VPN tanpa domain carian menuntut segala-galanya, jadi mengutamakannya juga menghantar pertanyaan awam ke dalam terowong dan, dalam reka bentuk terowong berpecah, ke tempat resolver korporat memajukan.

Keutamaan menentukan susunan, senarai carian menentukan pemilikan

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Senarai carian ialah pernyataan pemilikan. Domain kosong seperti corp.example menjadi akhiran carian dan domain penghalaan. Bentuk khusus penghalaan ~corp.example menghantar carian di bawah akhiran itu ke sambungan ini tanpa menambah domain pada nama pendek. Tilde itulah perbezaan antara «tanya pelayan ini» dan «tanya pelayan ini dan selesaikan taipan saya».

Gunakan kedua-dua bentuk apabila pengguna menaip nama hos pendek dan rekod juga dialamatkan dengan nama yang layak sepenuhnya. Gunakan bentuk penghalaan sahaja apabila anda mahu pemisahan tanpa mengubah cara resolver melengkapkan nama kosong.

Kemudian jadikan keutamaan itu eksplisit dan aktifkan semula:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Keutamaan negatif ialah cara berdokumen untuk berkata «utamakan sambungan ini», dan menetapkan kedua-dua keluarga alamat mengekalkan tingkah laku yang konsisten pada hos dengan sambungan IPv6. Menukar sifat tanpa mengaktifkan semula sambungan tidak mengubah apa-apa yang sedang berjalan, sebab itulah urutan berakhir dengan up yang eksplisit.

Biarkan systemd-resolved memegang pemisahan

Pemalam dnsmasq lalai menyalurkan pertanyaan ke satu resolver setempat, jadi pemisahan setiap pautan kekal kasar. systemd-resolved mendedahkan pemisahan setiap pautan, dan resolvectl query menamakan pautan yang menjawab.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Selepas itu pautan korporat membawa corp.example dan resolver awam melayani selebihnya. Apabila pertanyaan sampai ke pautan yang salah, arahan itu menamakan pautan yang menjawabnya, dan mengetahui perkara itu lebih baik daripada hanya mengetahui alamatnya.

Padankan reka bentuk DNS dengan jenis terowong

Reka bentuk privasi yang menghantar semuanya melalui terowong tidak sepatutnya membawa senarai pemisahan, kerana ia akan memulangkan nama awam kepada resolver setempat dan membatalkan niatnya. Reka bentuk terowong berpecah memerlukannya: tanpanya resolver korporat melihat setiap pertanyaan awam, dan persediaan rosak pada saat terowong jatuh.

Kemudian ada kill switch yang menyekat DNS di luar terowong. Nama diselesaikan untuk zon terowong dan gagal di tempat lain sementara sambungan benar-benar sihat. Jawapan yang boleh dilaksanakan ialah kebenaran jelas untuk resolver LAN atau cache setempat yang hanya memajukan zon korporat, dan kedua-duanya ialah pengecualian yang mempunyai pemilik, bukan kecacatan dalam terowong.

Profil yang menulis semula konfigurasi resolver semasa antara muka bermula berkelakuan hampir sama: sebaik sahaja resolver setempat tidak dapat dicapai, hanya nama yang diketahui terowong akan diselesaikan. Apa pun mekanisme yang terpakai, catat nama mana yang sepatutnya berfungsi dalam setiap keadaan, dan berikan senarai itu kepada sesiapa yang mengendalikan laporan.

Sahkan setiap pautan, kemudian sekali lagi selepas menyambung semula

Tanya satu nama dalaman dan satu nama awam, dan lihat ke mana pertanyaan itu sebenarnya pergi. Halaman pemeriksaan kebocoran memberitahu anda resolver mana yang menjawab, bukan pautan mana yang dipilih sistem, jadi ia tidak menyatakan apa-apa tentang susunan yang baru anda konfigurasikan.

Jalankan kedua-dua pertanyaan sekali lagi selepas memutuskan dan menyambung semula. Keutamaan digunakan semula apabila sambungan diaktifkan, dan pautan simbolik lama boleh bertahan melalui peningkatan yang tiada siapa ingat. Apa yang anda mahu catat pada akhirnya ialah resolver mana yang memiliki akhiran mana, tambah pemeriksaan yang masih sah esok.