DNS VPN mengambil setiap pencarian: perbaiki dns-priority di NetworkManager

Sambungkan VPN kantor dan tiba-tiba setiap pencarian nama menuju resolver perusahaan. Nama publik masih terurai, jadi tidak ada yang tampak rusak sampai nama printer lokal gagal atau catatan split-horizon mengembalikan alamat kantor. Pada sebagian pemasangan Fedora yang terjadi justru sebaliknya: resolver penyedia tetap menjawab setelah terowongan aktif. Keduanya satu pertanyaan — resolver mana yang memiliki kueri ini — dan pada sistem NetworkManager jawabannya hidup di properti DNS tiap koneksi.

Dua koneksi, satu resolver pemenang

Setiap koneksi menyatakan prioritas DNS. Koneksi biasa memakai 50 secara bawaan dan koneksi VPN memakai 0, dan nilai yang lebih rendah menang. Bawaan itulah sebabnya koneksi VPN diam-diam mengalahkan tautan kabel untuk setiap domain yang diklaimnya: nol mengalahkan lima puluh tanpa ada yang memilihnya.

Prioritas mengurutkan para kandidat. Prioritas tidak membatasi apa yang ditanyakan kepada pemenang. Koneksi VPN tanpa domain pencarian mengklaim segalanya, jadi memprioritaskannya juga mengirim kueri publik ke dalam terowongan dan, pada desain terowongan terbelah, ke tempat resolver perusahaan meneruskannya.

Prioritas menentukan urutan, daftar pencarian menentukan kepemilikan

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

Daftar pencarian adalah pernyataan kepemilikan. Domain telanjang seperti corp.example menjadi akhiran pencarian dan domain perutean. Bentuk khusus perutean ~corp.example mengirim pencarian di bawah akhiran itu ke koneksi ini tanpa menambahkan domain ke nama pendek. Tilde itulah bedanya antara «tanyakan server ini» dan «tanyakan server ini dan selesaikan pengetikan saya».

Pakai kedua bentuk saat pengguna mengetik nama host pendek dan catatan juga dialamatkan dengan nama yang sepenuhnya memenuhi syarat. Pakai hanya bentuk perutean saat Anda menginginkan pemisahan tanpa mengubah cara resolver melengkapi nama telanjang.

Lalu buat preferensinya eksplisit dan aktifkan ulang:

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"

Prioritas negatif adalah cara terdokumentasi untuk mengatakan «utamakan koneksi ini», dan menetapkan kedua keluarga alamat menjaga perilakunya konsisten pada host dengan konektivitas IPv6. Mengubah properti tanpa mengaktifkan ulang koneksi tidak mengubah apa pun yang sedang berjalan, karena itulah urutannya berakhir dengan perintah up yang eksplisit.

Biarkan systemd-resolved memegang pemisahannya

Plugin dnsmasq bawaan mengalirkan kueri ke satu resolver lokal, sehingga pemisahan per tautan tetap kasar. systemd-resolved memaparkan pemisahan per tautan, dan resolvectl query menyebut tautan 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

Setelah itu tautan perusahaan membawa corp.example dan resolver publik melayani sisanya. Saat kueri mencapai tautan yang salah, perintah itu menyebut tautan yang menjawabnya, dan mengetahui hal itu lebih baik daripada hanya mengetahui alamatnya.

Sesuaikan desain DNS dengan jenis terowongan

Desain privasi yang mengirim semuanya lewat terowongan sebaiknya tidak membawa daftar pemisahan, karena itu akan mengembalikan nama publik ke resolver lokal dan membatalkan maksudnya. Desain terowongan terbelah memerlukannya: tanpanya resolver perusahaan melihat setiap kueri publik, dan penyiapannya rusak begitu terowongan jatuh.

Lalu ada kill switch yang memblokir DNS di luar terowongan. Nama terurai untuk zona terowongan dan gagal di tempat lain sementara koneksinya benar-benar sehat. Jawaban yang bisa dipakai adalah izin tegas untuk resolver LAN atau cache lokal yang hanya meneruskan zona perusahaan, dan keduanya merupakan pengecualian dengan pemilik, bukan cacat pada terowongan.

Profil yang menulis ulang konfigurasi resolver saat antarmuka mulai berperilaku hampir sama: begitu resolver lokal tidak terjangkau, hanya nama yang dikenal terowongan yang akan terurai. Mekanisme apa pun yang berlaku, catat nama mana yang seharusnya bekerja pada tiap keadaan, dan berikan daftar itu kepada siapa pun yang menangani laporan.

Verifikasi per tautan, lalu sekali lagi setelah menyambung ulang

Tanyakan satu nama internal dan satu nama publik, dan lihat ke mana kueri sebenarnya pergi. Halaman pemeriksa kebocoran memberi tahu resolver mana yang menjawab, bukan tautan mana yang dipilih sistem, jadi halaman itu tidak mengatakan apa pun tentang urutan yang baru saja Anda atur.

Jalankan kedua kueri lagi setelah memutus dan menyambung ulang. Prioritas diterapkan ulang saat koneksi aktif, dan tautan simbolis lama bisa bertahan melewati pembaruan yang tidak diingat siapa pun. Yang ingin Anda catat pada akhirnya adalah resolver mana yang memiliki akhiran mana, plus pemeriksaan yang masih berlaku besok.