Mengapa nama server resolve ke alamat VPN-nya setelah dial-in

Server file kantor menjawab pada alamat LAN-nya sepanjang pagi, lalu pengguna jarak jauh dial-in dan nama mulai resolve ke alamat tunnel sebagai gantinya. Tidak ada yang diedit di DNS secara manual, dan itulah petunjuknya: catatan itu diterbitkan oleh mesin itu sendiri. Tiga kondisi menentukan apakah Anda memperbaiki registrar, catatan, atau pandangan klien, dan salah urutan berarti catatan kembali setelah koneksi berikutnya.

Dua alamat, satu nama, tiga kondisi

Server Windows multihomed dapat memiliki alamat LAN, satu atau lebih alamat dial-in, dan kadang kartu jaringan kedua. Setiap antarmuka dapat mendaftarkan alamatnya sendiri di DNS jika pendaftaran dinamis diizinkan untuknya. Saat adaptor PPP mendaftar, nama host yang sama memperoleh alamat yang hanya dapat dijangkau oleh rekan tunnel, dan klien LAN menerimanya sebagai jawaban yang sah.

Tiga kondisi menentukan perbaikannya. Pertama, apakah alamat tambahan itu dapat dijangkau dari klien yang menerimanya? Kedua, apakah ada konsumen yang masih bergantung pada pendaftaran itu? Ketiga, apakah catatan itu dinamis dan karena itu dapat kembali, atau statis dan karena itu entri yang disengaja?

Jawab itu sebelum menyentuh apa pun. Jika alamat tidak dapat dijangkau dari jaringan yang bertanya, pembersihan cache klien tidak akan memperbaikinya lama. Jika ada yang bergantung padanya, seperti jalur manajemen yang digunakan oleh rekan tunnel sendiri, menghapusnya justru memutus jalur itu. Dan catatan dinamis yang dihapus tanpa menangani penerbitnya akan muncul lagi pada peristiwa pendaftaran berikutnya.

Baca catatan sebelum mengubah registrar

Kueri nama lengkap yang sepenuhnya memenuhi syarat dari jaringan yang melaporkan masalahnya, dan bandingkan jawabannya dengan antarmuka serta pendengar server yang sebenarnya. Satu nama yang mengembalikan beberapa alamat adalah hal normal; pertanyaannya adalah apakah setiap alamat dapat 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

Kueri pertama memakai resolver lokal, kueri kedua bertanya langsung ke server DNS tertentu, dan kueri ketiga melakukan hal yang sama dari PowerShell di Windows. Membandingkannya memisahkan cache klien yang usang dari jawaban otoritatif. Jika kueri langsung sudah mengembalikan alamat tunnel, masalahnya ada pada data yang dipublikasikan, bukan cache lokal.

Catat stempel waktu catatan dan apakah konsol DNS menampilkannya sebagai dinamis. Satu atribut itu memberi tahu Anda kondisi mana dari tiga kondisi di atas yang berlaku, dan itulah perbedaan antara pembersihan lima menit dan perbaikan yang bertahan.

Perbaiki penerbit atau catatannya, tetapi ketahui yang mana

Jika catatan itu dinamis dan tidak diinginkan, perbaikan yang tahan lama adalah mencegah antarmuka itu mendaftar. Windows menyediakan pengaturan pendaftaran per antarmuka, dan layanan klien DNS menerbitkan ulang pada koneksi atau perubahan alamat berikutnya. Mematikan pendaftaran untuk adaptor dial-in membiarkan pendaftaran adaptor LAN utuh, yang biasanya memang yang Anda inginkan.

Berhati-hatilah dengan sakelar yang berlaku untuk seluruh mesin. Pengaturan global yang menonaktifkan pembaruan dinamis memengaruhi setiap antarmuka pada host itu, termasuk antarmuka yang pendaftarannya diandalkan klien lain. Pada pengendali domain, kehati-hatian yang sama berlaku lebih kuat, karena host juga dapat memiliki catatan lokasi layanan yang menjadi sandaran klien untuk masuk.

Jika catatan itu statis, catatan itu diletakkan di sana dengan sengaja dan percakapannya adalah dengan orang yang meletakkannya. Menghapus catatan statis karena hari ini tidak nyaman menghilangkan satu-satunya bukti mengapa catatan itu ada. Dalam kedua kasus, hapus jawaban usang hanya setelah penerbitnya ditangani, dan catat apa yang Anda ubah agar orang berikutnya dapat membedakan entri yang disengaja dari kecelakaan.

Verifikasi dari jaringan klien yang gagal

Verifikasi berada di jaringan yang melaporkan gejalanya, bukan di server. Bersihkan cache resolver klien melalui mekanisme yang didukungnya, lalu ulangi pencarian asli dan koneksi layanan asli dengan nama.

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

Perintah pertama membersihkan cache resolver Windows, dan yang kedua menunjukkan apakah nama itu di-cache lagi dan alamat mana yang disimpan. Koneksi server yang berhasil ke dirinya sendiri tidak membuktikan apa pun tentang klien LAN, dan menghapus rute ke alamat yang tidak diinginkan tidak memperbaiki apa yang dipublikasikan DNS.

Terakhir, ulangi peristiwa yang dahulu memasukkan alamat itu: hubungkan kembali klien VPN, atau perbarui sesi dial-in. Periksa lagi nama yang dipublikasikan setelah perubahan siklus hidup itu. Perbaikan yang hanya bertahan sampai koneksi berikutnya adalah pembersihan, bukan perbaikan, dan mengetahui mana yang Anda lakukan adalah perbedaan antara menutup tiket dan membukanya lagi minggu depan.