VPN mengambil alih DNS dan merosakkan nama tempatan: baiki senarai

Terowong naik, intranet dimuatkan, dan nama pencetak berhenti diselesaikan. Atau sebaliknya: nama tempatan masih berfungsi sementara semua yang di dalam rangkaian korporat tamat masa. Kedua-dua gejala datang dari tempat yang sama, senarai penyelesai yang ditulis semula oleh klien VPN semasa ia bersambung.

Baiki senarai itu dengan sengaja, kemudian tangani mekanisme push secara berasingan. Laluan ialah topik ketiga dan bukan yang dibaiki di sini.

Senarai mana yang sebenarnya digunakan oleh apl

Windows menyelesaikan melalui tetapan peringkat antara muka dan bukan melalui apa yang ditunjukkan oleh dialog, jadi mulakan dengan senarai berkesan bagi setiap antara muka. Alias lebih penting daripada nama yang dipaparkan, kerana setiap arahan di bawah menuju ke satu antara muka. Tersilap alias dan pembaikan akan mendarat pada penyesuai yang salah. Ia akan kelihatan berfungsi sehingga sambungan semula seterusnya, apabila entri terowong sendiri kembali.

Persoalannya ialah pelayan mana yang berada di hadapan, dan sama ada ia datang sebagai entri statik atau sebagai pajakan DHCP. Kedua-dua fakta menentukan pembaikan mana yang tersedia untuk anda.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Baca output untuk penyesuai terowong dan untuk penyesuai fizikal, dan catat setiap alamat pada setiap satu. Entri statik boleh dibuang oleh dasar atau skrip; entri yang dibekalkan DHCP terikat pada pajakan dan akan kembali, yang mengubah pembaikan yang patut anda pilih. Nama dalam rangkaian jauh diselesaikan oleh penyelesai yang diumumkan, nama pada LAN tempatan oleh penyesuai fizikal, dan pertanyaan pergi ke senarai yang dirujuk dahulu.

Buang pelayan yang ditolak, atau letakkan mereka lebih rendah

Padam pelayan yang ditolak apabila tiada apa-apa di dalam terowong memerlukannya, kerana penyelesai penyesuai fizikal mengambil alih semula. Kekalkan hanya jika rangkaian jauh memiliki zon yang hanya pelayan itu boleh jawab, dan dalam kes itu letakkan penyelesai tempatan di hadapannya. Dua arahan di bawah merangkumi kedua-dua pilihan, jadi pilih yang sesuai dengan keadaan dan bukannya menjalankan kedua-duanya.

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 dirujuk dahulu, jadi alamat yang ditolak kekal tersedia tetapi berhenti menjadi jawapan lalai bagi setiap pertanyaan. Bendera validate=no melangkau ujian kebolehsampaian yang sering gagal semasa terowong masih menetap, jadi sahkan hasilnya dengan arahan show dan bukannya mempercayai kod keluar.

Dua had wajar diketahui sebelum bergantung pada ini. Windows tidak akan memadam pelayan yang datang melalui DHCP melalui netsh, dan nilai itu kekal sebagai DhcpNameServer di bawah kunci registri antara muka, jadi penyuntingan registri ialah usaha terakhir yang mesti disemak semula selepas pajakan seterusnya. Susunan pengikatan penyesuai juga bukan mekanisme kedudukan yang boleh dipercayai, kerana klien VPN boleh memasukkan entrinya sendiri di bahagian atas senarai.

Di mana push boleh ditapis

Pembaikan yang lebih baik membuang pilihan sebelum ia digunakan. Klien Community OpenVPN boleh menapis direktif yang ditolak mengikut nama, yang membiarkan konfigurasi pelayan tidak disentuh.

pull-filter ignore "dhcp-option DNS "

Ruang di hujung milik padanan dan penapis menamakan pilihan dan bukan alamat pelayan. Jika profil juga mengandungi direktif block-outside-dns, membuangnya mengubah perlindungan kebocoran dan bukan penyelesaian nama, jadi putuskan perkara itu secara berasingan daripada menggabungkan dua suntingan.

Untuk satu nama hos yang degil, satu baris dalam fail hosts Windows lebih mantap daripada menyusun semula penyelesai untuk seluruh mesin. Ia juga tidak kelihatan kepada orang seterusnya, jadi catatkan di tempat konfigurasi mesin didokumenkan.

Jadikan pembaikan bertahan selepas sambungan semula

Penyelesaian nama mesti diuji dua kali, sekali terhadap pelayan yang dipilih dan sekali dalam bentuk yang digunakan oleh apl. Pasangan itu memisahkan masalah susunan penyelesai daripada pelayan yang langsung tidak menjawab. Melangkau ujian pertama membiarkan kedua-dua punca kekal kusut.

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

Sambung semula terowong dan ulangi kedua-dua arahan. Apa yang anda ubah secara manual hanya bertahan sehingga sambungan seterusnya, kerana klien membina semula keadaan penyelesainya semasa menaikkan penyesuai. Letakkan baris netsh dalam skrip sambungan yang disokong klien anda, biarkan skrip itu selesai dengan jayanya, dan tambah tunggu sebentar sebelum ia dijalankan. Klien yang menggunakan DNS selepas skrip akan menimpa hasilnya juga.

Jika nama awam diselesaikan dan nama dalaman masih gagal selepas pembaikan, senarai penyelesai bukan lagi suspek. Pertanyaan itu mungkin tidak sampai ke pelayan langsung, yang menunjuk kepada penghalaan atau peraturan firewall dan bukan tetapan DNS lain. Catat alias antara muka dan alamat yang anda putuskan, kerana kedua-duanya berbeza antara mesin dan tiada satu pun bertahan pembinaan semula sendirian.