VPN mengambil alih DNS dan merusak nama lokal: perbaiki daftarnya

Tunnel menyala, intranet termuat, dan nama printer berhenti diresolusi. Atau sebaliknya: nama lokal masih berfungsi sementara semua yang ada di dalam jaringan perusahaan kehabisan waktu. Kedua gejala datang dari tempat yang sama, daftar resolver yang ditulis ulang oleh klien VPN saat terhubung.

Perbaiki daftar itu dengan sengaja, lalu tangani mekanisme push secara terpisah. Rute adalah topik ketiga dan bukan yang diperbaiki di sini.

Daftar mana yang sebenarnya dipakai aplikasi

Windows meresolusi lewat pengaturan tingkat antarmuka, bukan lewat apa yang ditampilkan sebuah dialog, jadi mulailah dari daftar efektif per antarmuka. Alias lebih penting daripada nama tampilan, karena setiap perintah di bawah menyapa sebuah antarmuka. Salah alias dan perbaikan akan mendarat di adaptor yang salah. Tampaknya berfungsi sampai penyambungan ulang berikutnya, saat entri milik tunnel kembali.

Pertanyaannya adalah server mana yang berada di depan, dan apakah mereka datang sebagai entri statis atau sebagai sewa DHCP. Kedua fakta menentukan perbaikan mana yang tersedia bagi Anda.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Baca keluaran untuk adaptor tunnel dan adaptor fisik, dan catat setiap alamat pada masing-masing. Entri statis bisa dihapus oleh kebijakan atau skrip; entri yang diberikan DHCP terikat pada sewa dan akan kembali, yang mengubah perbaikan yang harus Anda pilih. Nama di jaringan jauh diresolusi oleh resolver yang diumumkan, nama di LAN lokal oleh adaptor fisik, dan kueri menuju daftar yang diperiksa lebih dulu.

Hapus server yang didorong, atau letakkan mereka lebih rendah

Hapus server yang didorong ketika tidak ada apa pun di dalam tunnel yang membutuhkannya, karena resolver milik adaptor fisik mengambil alih lagi. Pertahankan hanya jika jaringan jauh memiliki zona yang hanya server-nya yang bisa menjawab, dan dalam hal itu letakkan resolver lokal di depan mereka. Dua perintah di bawah mencakup kedua pilihan, jadi pilih yang sesuai situasi alih-alih menjalankan keduanya.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Indeks 1 diperiksa lebih dulu, sehingga alamat yang didorong tetap tersedia tetapi berhenti menjadi jawaban bawaan untuk setiap kueri. Tanda validate=no melewati uji keterjangkauan yang sering gagal selagi tunnel masih menetap, jadi pastikan hasilnya dengan perintah show alih-alih memercayai kode keluar.

Dua batas perlu diketahui sebelum mengandalkan ini. Windows tidak akan menghapus server yang datang lewat DHCP melalui netsh, dan nilai-nilai itu bertahan sebagai DhcpNameServer di bawah kunci registri antarmuka, jadi penyuntingan registri adalah upaya terakhir yang harus diperiksa ulang setelah sewa berikutnya. Urutan pengikatan adaptor juga bukan mekanisme peringkat yang andal, karena klien VPN dapat menyisipkan entrinya sendiri di bagian atas daftar.

Di mana push bisa disaring

Perbaikan yang lebih baik menghapus opsi sebelum diterapkan. Klien Community OpenVPN dapat menyaring direktif yang didorong berdasarkan nama, yang membiarkan konfigurasi server tidak tersentuh.

pull-filter ignore "dhcp-option DNS "

Spasi di akhir termasuk dalam pencocokan dan penyaring menyebut opsi, bukan alamat server. Jika profil juga memuat direktif block-outside-dns, menghapusnya mengubah perlindungan kebocoran, bukan resolusi nama, jadi putuskan itu secara terpisah alih-alih menggabungkan kedua suntingan.

Untuk satu nama host yang keras kepala, satu baris di berkas hosts Windows lebih mantap daripada menyusun ulang resolver untuk seluruh mesin. Itu juga tak terlihat bagi orang berikutnya, jadi catat di tempat konfigurasi mesin didokumentasikan.

Buat perbaikan bertahan melewati penyambungan ulang

Resolusi harus diuji dua kali, sekali terhadap server yang dipilih dan sekali dalam bentuk yang dipakai aplikasi. Pasangan itu memisahkan masalah urutan resolver dari server yang sama sekali tidak menjawab. Melewati uji pertama membuat kedua penyebab tetap kusut.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Sambungkan ulang tunnel dan ulangi kedua perintah. Apa pun yang Anda ubah dengan tangan hanya bertahan sampai koneksi berikutnya, karena klien membangun ulang status resolver-nya saat menaikkan adaptor. Letakkan baris netsh di skrip koneksi yang didukung klien Anda, biarkan skrip itu selesai dengan sukses, dan tambahkan jeda singkat sebelum dijalankan. Klien yang menerapkan DNS setelah skrip akan menimpa hasilnya bagaimanapun.

Jika nama publik teresolusi dan nama internal masih gagal setelah perbaikan, daftar resolver bukan lagi tersangkanya. Kueri mungkin sama sekali tidak mencapai server, yang menunjuk ke perutean atau aturan firewall dan bukan ke pengaturan DNS lain. Catat alias antarmuka dan alamat yang Anda pilih, karena keduanya berbeda antar mesin dan tidak ada yang bertahan sendiri saat dibangun ulang.