Mengapa nama pelayan resolve ke alamat VPN-nya selepas dial-in

Pelayan fail pejabat menjawab pada alamat LAN-nya sepanjang pagi, kemudian pengguna jauh dial-in dan nama mula resolve ke alamat terowong sebagai gantinya. Tiada apa yang diedit dalam DNS secara manual, dan itulah petunjuknya: rekod itu diterbitkan oleh mesin itu sendiri. Tiga syarat menentukan sama ada anda membaiki pendaftar, rekod atau pandangan klien, dan urutan yang salah bermakna rekod kembali selepas sambungan seterusnya.

Dua alamat, satu nama, tiga syarat

Pelayan Windows berbilang antara muka boleh mempunyai alamat LAN, satu atau lebih alamat dial-in dan kadangkala kad rangkaian kedua. Setiap antara muka boleh mendaftarkan alamatnya sendiri dalam DNS jika pendaftaran dinamik dibenarkan untuknya. Apabila penyesuai PPP mendaftar, nama hos yang sama memperoleh alamat yang hanya boleh dicapai oleh rakan terowong, dan klien LAN menerimanya sebagai jawapan yang sah.

Tiga syarat menentukan pembaikan. Pertama, adakah alamat tambahan itu boleh dicapai daripada klien yang menerimanya? Kedua, adakah mana-mana pengguna masih bergantung pada pendaftaran itu? Ketiga, adakah rekod itu dinamik dan oleh itu boleh kembali, atau statik dan oleh itu entri yang disengajakan?

Jawab itu sebelum menyentuh apa-apa. Jika alamat itu tidak boleh dicapai daripada rangkaian yang bertanya, pembersihan cache klien tidak akan membaikinya untuk masa yang lama. Jika sesuatu bergantung padanya, seperti laluan pengurusan yang digunakan oleh rakan terowong sendiri, membuangnya sebaliknya memecahkan laluan itu. Dan rekod dinamik yang dipadam tanpa menangani penerbitnya akan muncul semula pada peristiwa pendaftaran seterusnya.

Baca rekod sebelum menukar pendaftar

Tanya nama penuh yang layak dengan tepat daripada rangkaian yang melaporkan masalah itu, dan bandingkan jawapannya dengan antara muka dan pendengar sebenar pelayan. Satu nama yang mengembalikan beberapa alamat adalah normal; persoalannya ialah sama ada setiap satu boleh digunakan oleh klien yang menerimanya.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

Pertanyaan pertama menggunakan penyelesai tempatan, yang kedua bertanya terus kepada pelayan DNS tertentu, dan yang ketiga melakukan perkara yang sama daripada PowerShell di Windows. Membandingkannya memisahkan cache klien lama daripada jawapan berwibawa. Jika pertanyaan langsung sudah mengembalikan alamat terowong, masalahnya ialah data yang diterbitkan dan bukan cache tempatan.

Catat cap masa rekod dan sama ada konsol DNS menunjukkannya sebagai dinamik. Sifat tunggal itu memberitahu anda syarat mana antara tiga syarat di atas yang terpakai, dan itulah perbezaan antara pembersihan lima minit dan pembaikan yang bertahan.

Baiki penerbit atau rekod, tetapi ketahui yang mana

Jika rekod itu dinamik dan tidak diingini, pembaikan yang tahan lama ialah menghalang antara muka itu daripada mendaftar. Windows menyediakan tetapan pendaftaran bagi setiap antara muka, dan perkhidmatan klien DNS menerbitkan semula pada sambungan atau perubahan alamat seterusnya. Mematikan pendaftaran untuk penyesuai dial-in membiarkan pendaftaran penyesuai LAN utuh, yang biasanya memang yang anda mahu.

Berhati-hatilah dengan suis yang terpakai kepada seluruh mesin. Tetapan global yang melumpuhkan kemas kini dinamik menjejaskan setiap antara muka pada hos itu, termasuk yang pendaftarannya diharapkan oleh klien lain. Pada pengawal domain, kehati-hatian yang sama terpakai dengan lebih kuat, kerana hos itu mungkin juga memiliki rekod lokasi perkhidmatan yang menjadi sandaran klien untuk log masuk.

Jika rekod itu statik, ia diletakkan di sana dengan sengaja dan perbualannya ialah dengan orang yang meletakkannya. Memadam rekod statik kerana ia menyusahkan hari ini menghapuskan satu-satunya bukti mengapa ia wujud. Dalam kedua-dua kes, padam jawapan lama hanya selepas penerbitnya ditangani, dan catat apa yang anda ubah supaya orang seterusnya dapat membezakan entri yang disengajakan daripada kemalangan.

Sahkan daripada rangkaian klien yang gagal

Pengesahan adalah milik rangkaian yang melaporkan simptom itu, bukan pelayan. Kosongkan cache penyelesai klien melalui mekanisme yang disokongnya, kemudian ulangi carian asal dan sambungan perkhidmatan asal dengan nama.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Perintah pertama mengosongkan cache penyelesai Windows, dan yang kedua menunjukkan sama ada nama itu di-cache semula dan alamat mana yang disimpan. Sambungan berjaya pelayan dengan dirinya sendiri tidak membuktikan apa-apa tentang klien LAN, dan membuang laluan ke alamat yang tidak diingini tidak membetulkan apa yang diterbitkan oleh DNS.

Akhir sekali, ulangi peristiwa yang dahulunya memasukkan alamat itu: sambungkan semula klien VPN, atau perbaharui sesi dial-in. Semak semula nama yang diterbitkan selepas perubahan kitaran hayat itu. Pembaikan yang hanya bertahan sehingga sambungan seterusnya ialah pembersihan, bukan pembaikan, dan mengetahui yang mana satu anda lakukan ialah perbezaan antara menutup tiket dan membukanya semula minggu depan.