Server DNS salah di VPN Windows: metrik, urutan pengikatan, atau akhiran

Klien Windows bisa memiliki tunnel yang berfungsi, membawa resolver korporat, dan tetap mengirim nama internal ke router rumah. Tiga mekanisme berbeda menentukan server mana yang menjawab, dan ketiganya gagal dengan cara berbeda. Anda tidak perlu memperbaiki ketiganya: gejalanya memberi tahu mana yang sedang bermain. Pohon keputusan di bawah memakan beberapa menit dan mencegah hasil yang biasa terjadi, yaitu perubahan metrik, penataan ulang registri, dan aturan NRPT datang bersamaan dan tidak ada yang tahu mana yang melakukan sesuatu.

Tiga mekanisme menentukan, dan biasanya satu yang salah

Metrik antarmuka mengurutkan adaptor untuk keluarga alamat tertentu. Urutan pengikatan di bawah Tcpip\Linkage adalah daftar pengenal antarmuka selevel mesin yang masih dibaca jalur kode lama. Tabel Kebijakan Resolusi Nama (NRPT) mengikat ruang nama ke server tertentu, dan daftar akhiran menentukan apakah nama pendek diperluas sama sekali. Ketiganya independen, karena itu resolver yang benar di adaptor VPN kalah oleh preferensi usang di tempat lain.

Tidak satu pun mekanisme ini adalah sisi seberang tunnel. Jika server yang didorong VPN tidak dapat me-resolve nama itu, setiap pengaturan di sisi klien hanya hiasan, jadi keputusan pertama adalah apakah resolver itu sendiri bisa menjawab bila ditanya langsung.

Keputusan satu: bisakah resolver yang didorong menjawab sama sekali?

Tanyakan ke server secara eksplisit dan bandingkan dengan pencarian biasa. Selisih antara kedua jawaban memisahkan masalah pemilihan dari masalah keterjangkauan, dan inilah percabangan tercepat di sini:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Jika yang pertama berhasil dan yang kedua gagal, resolver dapat dijangkau dan Windows memilih dengan buruk; lanjut ke keputusan ruang nama dan urutan di bawah. Jika yang pertama juga gagal, tidak ada yang membantu di klien: periksa apakah UDP dan TCP 53 mencapai server lewat tunnel, apakah tidak ada firewall host di server yang membuang kumpulan itu, dan apakah penerus milik server itu sendiri sehat.

Berhenti di percabangan ini. Menerapkan aturan NRPT pada resolver yang tidak dapat Anda jangkau menghasilkan kegagalan yang sama dengan konfigurasi lebih banyak untuk dibatalkan, dan menyembunyikan kesalahan sebenarnya di balik aturan yang tampak berwenang.

Keputusan dua: satu ruang nama, atau setiap kueri?

Cakupan menentukan alatnya. Bila hanya nama korporat yang gagal, ikat ruang namanya alih-alih menata ulang mesin: aturan NRPT mengirim akhiran itu ke resolver tunnel dan membiarkan sisanya. Bila setiap pencarian terkena, masalahnya adalah preferensi adaptor global, dan metrik adalah tempat memulai karena tidak mengubah satu pun pengaturan server.

Atur metrik per keluarga alamat, pada kedua antarmuka, lalu pastikan urutannya:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Ganti 11 dengan ifIndex adaptor tunnel dari baris di atas; jika 11 adalah adaptor LAN, perintah yang sama menurunkan jalur yang salah. Menaikkan adaptor LAN justru mencapai urutan yang sama dari sisi lain: netsh int ip set interface interface="Ethernet" metric=15, dan netsh int ipv6 set interface interface="Ethernet" metric=15 untuk keluarga kedua, karena int ip hanya menyentuh IPv4.

Urutan pengikatan adalah jalan terakhir, bukan langkah pertama. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage menyimpan daftar Bind pengenal perangkat, dan memindahkan pengenal tunnel ke depan memang mengubah adaptor mana yang ditanya lebih dulu, tetapi itu nilai registri selevel mesin tanpa cakupan per ruang nama. Ekspor dulu sebelum menyunting, lalu sambungkan ulang tunnel agar urutannya berlaku pada keadaan yang diharapkan klien.

Untuk satu ruang nama, pilih instrumen yang lebih sempit:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Keputusan tiga: apakah perbaikan bertahan setelah penyambungan ulang?

Metrik yang bertahan sampai sambungan dial-up berikutnya tidak pernah disimpan. L2TP/IPsec dan profil koneksi lain dibuat ulang saat koneksi dimulai, jadi nilai tersimpan hidup di entri buku telepon sebagai IpInterfaceMetric, bukan hanya pada antarmuka aktif. Sebagian lingkungan menuliskan bidang itu lewat skrip justru karena alasan ini; yang lain mendorong preferensi dari kebijakan manajemen dan membiarkan titik akhir apa adanya.

Cache dan registrasi adalah lapisan terpisah. Menjalankannya setelah tunnel naik memperbaiki entri usang dan mendaftarkan klien ulang, tetapi keduanya tidak menata ulang adaptor:

ipconfig /registerdns
ipconfig /flushdns

Ada sakelar mati di lapisan yang sama. Menonaktifkan registrasi dinamis pada adaptor fisik mencegah klien mengumumkan alamat sisi VPN-nya dengan nama yang salah, dan itu perbaikan yang berbeda dari penyegaran di atas.

IPv6 layak mendapat barisnya sendiri dalam keputusan. Jika adaptor fisik memegang alamat IPv6 global sementara tunnel hanya membawa IPv4, Windows dapat memilih jalur tanpa tunnel untuk resolusi nama. Periksa keluarga itu secara terpisah, karena metrik yang diatur untuk IPv4 tidak mengatakan apa pun tentangnya:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Menonaktifkan IPv6 pada adaptor LAN menghapus jalur itu beserta protokolnya; perubahan metrik pada antarmuka IPv6, atau aturan NRPT untuk ruang nama korporat, mempertahankan keluarga itu dan memperbaiki preferensinya. Pilih yang lebih sempit kecuali Anda sudah memutuskan bahwa tautan itu tidak seharusnya memiliki IPv6.

Verifikasi dengan sumber yang disebut, dan pertahankan satu pemilik

Verifikasi dengan alat yang melaporkan sumber mana yang berlaku, bukan sekadar apakah halaman termuat:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Lalu pisahkan penyaringan dari pemilihan, karena dari dalam aplikasi keduanya tampak identik. block-outside-dns dari OpenVPN memblokir port 53 pada adaptor lain; ia tidak memilih resolver. Jika sekarang setiap kueri gagal, sebuah penyaring mungkin memblokir satu-satunya server yang dapat dijangkau; jika resolver yang dikonfigurasi diabaikan, urutan atau aturan ruang namanya salah. Mengubah keduanya sekaligus membuat kueri yang diblokir dan kueri yang diabaikan tak dapat dibedakan.

Pertahankan satu pemilik untuk kebijakan DNS: profil VPN, kebijakan manajemen, atau aturan NRPT, bukan dua di antaranya. Sebelum menutupnya:

• Resolver yang didorong menjawab bila disebut eksplisit, dan pencarian biasa memakainya.
• Aturan atau metrik yang Anda ubah mencakup keluarga alamat yang benar-benar membawa kueri.
• Pengaturan bertahan setelah pemutusan dan penyambungan ulang, atau Anda telah memindahkannya ke profil tersimpan.
• Tepat satu mekanisme yang berwenang, dan yang lain dibiarkan seperti semula.

Perlakukan urutan sebagai keadaan lingkungan, bukan sesuatu yang diselesaikan. Periksa ulang setelah penyambungan ulang dan setelah pembaruan Windows yang menyentuh tumpukan jaringan, karena keduanya dapat mengembalikan adaptor fisik ke depan.