Pelayan DNS salah dalam VPN Windows: metrik, susunan pengikatan atau akhiran

Klien Windows boleh mempunyai terowong yang berfungsi, membawa penyelesai korporat dan masih menghantar nama dalaman ke penghala rumah. Tiga mekanisme berbeza menentukan pelayan mana yang menjawab, dan ia gagal dengan cara berbeza. Anda tidak perlu membaiki ketiga-tiganya: gejala memberitahu anda yang mana sedang bermain. Pokok keputusan di bawah mengambil beberapa minit dan menghalang hasil biasa, di mana perubahan metrik, penyusunan semula pendaftaran dan peraturan NRPT tiba bersama-sama dan tiada siapa tahu yang mana melakukan sesuatu.

Tiga mekanisme menentukan, dan biasanya satu yang salah

Metrik antara muka menyusun penyesuai untuk keluarga alamat tertentu. Susunan pengikatan di bawah Tcpip\Linkage ialah senarai pengecam antara muka peringkat mesin yang masih dirujuk oleh laluan kod lama. Jadual Dasar Penyelesaian Nama (NRPT) mengikat ruang nama kepada pelayan tertentu, dan senarai akhiran menentukan sama ada nama pendek dikembangkan sama sekali. Ia bebas, sebab itu penyelesai yang betul pada penyesuai VPN kalah kepada keutamaan usang di tempat lain.

Tiada satu pun mekanisme ini ialah sebelah sana terowong. Jika pelayan yang ditolak oleh VPN tidak dapat menyelesaikan nama itu, setiap tetapan di sebelah klien hanyalah hiasan, jadi keputusan pertama ialah sama ada penyelesai itu sendiri boleh menjawab apabila ditanya secara langsung.

Keputusan satu: bolehkah penyelesai yang ditolak menjawab sama sekali?

Tanya pelayan secara eksplisit dan bandingkan dengan carian biasa. Jurang antara jawapan memisahkan masalah pemilihan daripada masalah capaian, dan di sini ia cabang terpantas:

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

Jika yang pertama berjaya dan yang kedua gagal, penyelesai boleh dicapai dan Windows memilih dengan buruk; pergi ke keputusan ruang nama dan susunan di bawah. Jika yang pertama juga gagal, tiada apa di klien akan membantu: semak sama ada UDP dan TCP 53 sampai ke pelayan melalui terowong, sama ada tiada tembok api hos di pelayan yang menggugurkan kumpulan itu, dan sama ada pemajukan pelayan itu sendiri sihat.

Berhenti di cabang ini. Menggunakan peraturan NRPT pada penyelesai yang tidak dapat anda capai menghasilkan kegagalan yang sama dengan lebih banyak konfigurasi untuk dibatalkan, dan ia menyembunyikan kerosakan sebenar di belakang peraturan yang kelihatan berwibawa.

Keputusan dua: satu ruang nama, atau setiap pertanyaan?

Skop menentukan alat. Apabila hanya nama korporat gagal, ikat ruang nama itu dan bukannya menyusun semula mesin: peraturan NRPT menghantar akhiran itu kepada penyelesai terowong dan membiarkan yang lain. Apabila setiap carian terjejas, masalahnya ialah keutamaan penyesuai global, dan metrik ialah tempat untuk bermula kerana ia tidak mengubah mana-mana tetapan pelayan.

Tetapkan metrik bagi setiap keluarga alamat, pada kedua-dua antara muka, dan sahkan susunannya selepas itu:

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

Gantikan 11 dengan ifIndex penyesuai terowong dari baris di atas; jika 11 ialah penyesuai LAN, arahan yang sama menurunkan laluan yang salah. Menaikkan penyesuai LAN sebaliknya mencapai susunan yang sama dari sebelah lain: netsh int ip set interface interface="Ethernet" metric=15, dan netsh int ipv6 set interface interface="Ethernet" metric=15 untuk keluarga kedua, kerana int ip hanya menyentuh IPv4.

Susunan pengikatan ialah pilihan terakhir dan bukan langkah pertama. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage menyimpan senarai Bind pengecam peranti, dan memindahkan pengecam terowong ke hadapan memang mengubah penyesuai mana yang ditanya dahulu, tetapi ia nilai pendaftaran peringkat mesin tanpa skop bagi setiap ruang nama. Eksport dahulu sebelum menyunting, kemudian sambung semula terowong supaya susunan terpakai dalam keadaan yang dijangka oleh klien.

Untuk satu ruang nama, utamakan alat yang lebih sempit:

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

Keputusan tiga: adakah pembaikan bertahan selepas sambungan semula?

Metrik yang bertahan sehingga sambungan dail berikutnya tidak pernah disimpan. L2TP/IPsec dan profil sambungan lain dicipta semula apabila sambungan bermula, jadi nilai tersimpan hidup dalam entri buku telefon sebagai IpInterfaceMetric, bukan hanya pada antara muka aktif. Sesetengah persekitaran menulis medan itu melalui skrip kerana sebab ini; yang lain menolak keutamaan daripada dasar pengurusan dan membiarkan titik akhir itu.

Cache dan pendaftaran ialah lapisan berasingan. Menjalankannya selepas terowong naik membaiki entri usang dan mendaftar semula klien, tetapi kedua-duanya tidak menyusun semula penyesuai:

ipconfig /registerdns
ipconfig /flushdns

Terdapat suis mati dalam lapisan yang sama. Melumpuhkan pendaftaran dinamik pada penyesuai fizikal menghalang klien mengumumkan alamat sebelah VPN di bawah nama yang salah, dan itu pembaikan berbeza daripada penyegaran di atas.

IPv6 berhak mendapat barisnya sendiri dalam keputusan. Jika penyesuai fizikal memegang alamat IPv6 global manakala terowong hanya membawa IPv4, Windows boleh mengutamakan laluan tanpa terowong untuk penyelesaian nama. Semak keluarga itu secara berasingan, kerana metrik yang ditetapkan untuk IPv4 tidak mengatakan apa-apa tentangnya:

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

Melumpuhkan IPv6 pada penyesuai LAN menghapuskan laluan itu dan protokol bersamanya; perubahan metrik pada antara muka IPv6, atau peraturan NRPT untuk ruang nama korporat, mengekalkan keluarga itu dan membaiki keutamaan. Pilih yang lebih sempit melainkan anda telah memutuskan pautan itu tidak sepatutnya mempunyai IPv6.

Sahkan dengan sumber yang dinamakan, dan kekalkan seorang pemilik

Sahkan dengan alat yang melaporkan sumber mana yang berkuat kuasa, bukan sekadar sama ada halaman dimuatkan:

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

Kemudian pisahkan penapisan daripada pemilihan, kerana dari dalam aplikasi kedua-duanya kelihatan sama. block-outside-dns OpenVPN menyekat port 53 pada penyesuai lain; ia tidak memilih penyelesai. Jika kini setiap pertanyaan gagal, penapis mungkin menyekat satu-satunya pelayan yang boleh dicapai; jika penyelesai yang dikonfigurasikan diabaikan, susunan atau peraturan ruang nama itu salah. Menukar kedua-duanya sekali gus menjadikan pertanyaan yang disekat dan pertanyaan yang diabaikan tidak dapat dibezakan.

Kekalkan seorang pemilik dasar DNS: profil VPN, dasar pengurusan atau peraturan NRPT, bukan dua daripadanya. Sebelum menutupnya:

• Penyelesai yang ditolak menjawab apabila dinamakan secara eksplisit, dan carian biasa menggunakannya.
• Peraturan atau metrik yang anda ubah meliputi keluarga alamat yang benar-benar membawa pertanyaan itu.
• Tetapan bertahan selepas pemutusan dan sambungan semula, atau anda telah memindahkannya ke profil tersimpan.
• Tepat satu mekanisme yang berwibawa, dan yang lain dibiarkan seperti asalnya.

Anggap susunan itu sebagai keadaan persekitaran dan bukan sesuatu yang diselesaikan. Semak semula selepas sambungan semula dan selepas kemas kini Windows yang menyentuh tindanan rangkaian, kerana mana-mana daripadanya boleh meletakkan penyesuai fizikal kembali di hadapan.