DNS publik berfungsi bukan berarti Active Directory bisa ditemukan

VPN tersambung, peramban membuka situs publik, dan laptop tetap tidak dapat masuk ke domain. Kesimpulan yang biasa diambil adalah DNS baik-baik saja karena nama terselesaikan. Itu tidak benar, dan alasannya adalah uji peramban hanya menguji satu pencarian dari rangkaian yang dibutuhkan klien yang tergabung ke domain. Penemuan domain meminta catatan layanan lebih dulu, lalu alamat pengendali yang disebut catatan itu, lalu rute ke porta yang didengarkan pengendali tersebut. Jawaban publik tidak memenuhi satu pun dari langkah itu.

Mitos: nama terselesaikan, jadi DNS sudah beres

Situs publik yang terselesaikan hanya memberi tahu bahwa suatu penyelesai menjawab satu kueri A atau AAAA untuk nama di zona publik. Active Directory memakai protokol yang sama untuk pertanyaan lain: di mana layanan domain, dan pengendali mana yang harus dipakai klien ini. Pertanyaan itu diungkapkan sebagai catatan SRV di bawah zona yang dinamai menurut domain, dan penyelesai publik rekursif tidak punya alasan menyimpannya.

Ketika catatan itu tidak ada, penyelesai mengembalikan jawaban negatif, yang merupakan jawaban DNS sah dan bukan pemadaman. Klien lalu kembali ke informasi pengendali yang tersimpan di tembolok jika ada, dan itulah sebabnya komputer meja dapat tampak baik selama berjam-jam lalu gagal setelah mulai ulang atau perubahan kata sandi.

Apa yang sebenarnya diminta klien domain, menurut urutan

Untuk domain seperti corp.example, kueri pencari umumnya adalah _ldap._tcp.dc._msdcs.corp.example. Jawaban SRV menyebut calon pengendali dan portanya, lalu klien memerlukan catatan alamat untuk nama host itu sebelum dapat membuka koneksi. Penemuan yang sadar situs menambahkan kueri di bawah subdomain situs, dan jawabannya menentukan pengendali mana yang diutamakan, bukan mana yang wajib.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Ikuti rangkaian itu dalam urutan tersebut, dari jaringan tempat masalah terjadi. Nama host yang terselesaikan ke alamat tak terjangkau adalah kegagalan perutean, bukan kegagalan DNS. Pengendali yang terjangkau tetapi catatan pencarinya hilang adalah kegagalan DNS, bukan kegagalan perutean. Keduanya menghasilkan keluhan pengguna yang mirip dan perbaikan yang sama sekali berbeda.

Mengapa penyelesai publik menjawab tetapi masuk tetap gagal

Jika adaptor memberikan penyelesai publik kepada klien, nama publik berfungsi dan ruang nama internal tidak. Menambahkan penyelesai publik kedua tidak menolong, karena keduanya tidak memegang zona itu. Daftar lazim “internal dulu, publik kemudian” pun tidak berperilaku seperti aturan per domain: jawaban negatif dari server pertama adalah jawaban yang sah, dan klien tidak mencoba server kedua lagi hanya karena jawabannya kosong.

Kedua penyelesai internal, jika Anda menjalankan dua, harus memegang ruang nama AD dan dapat dijangkau dari jaringan klien saat ini. Itulah bagian yang dirusak rancangan terowongan terpisah: VPN dapat membawa subnet terowongan sementara penyelesai internal berada pada prefiks yang tidak dirutekan terowongan, sehingga kueri keluar ke penyelesai yang tidak dapat menjawabnya.

Windows juga menerapkan kebijakan penyelesaian nama yang dapat mengarahkan ruang nama tertentu ke server tertentu, dan alamat DNS yang ditampilkan adaptor bukanlah seluruh cerita. Mengubah daftar adaptor tanpa mengubah kebijakan itu dapat membiarkan konfigurasi efektif tidak tersentuh, dan itulah sebabnya perbaikan yang tampak diterapkan tidak berefek.

Jaga DNS terowongan dan rutenya tetap sejalan

Profil VPN yang mendorong penyelesai tetapi tidak mendorong prefiks yang memuatnya menciptakan penyelesai yang tidak dapat dijangkau klien; profil yang mendorong prefiks tanpa penyelesai membiarkan klien bertanya ke yang lokal. Perlakukan pasangan itu sebagai satu butir konfigurasi dan periksa keduanya setelah setiap perubahan profil, karena dorongan yang diurutkan ulang atau kebijakan terowongan terpisah yang baru dapat memisahkan keduanya.

Periksa juga apa yang dilakukan klien dengan pengaturan yang didorong. Sebagian klien menerapkan server DNS hanya pada antarmuka terowongan dan membiarkan penyelesai adaptor fisik di tempatnya, sehingga mana yang menang bergantung pada metrik antarmuka dan nama yang ditanyakan. Jika jawaban internal hanya datang ketika adaptor fisik dinonaktifkan, itulah mekanisme yang harus diperbaiki, bukan catatan domain.

Terima dengan panggilan penemuan dan satu operasi hidup

Uji penerimaan yang berguna menjalankan kueri pencari lalu melakukan satu operasi terautentikasi sungguhan, seperti membuka berbagi pakai yang didukung direktori atau meminta tiket. Lakukan sebelum peralihan VPN dan lagi sesudahnya, pada mesin yang sama, tanpa mulai ulang di antaranya. Kredensial di tembolok dan sesi yang sudah terbuka akan dengan senang hati membuat jalur rusak tampak sehat, jadi login meja yang berhasil bukanlah ujinya.

Rekomendasi klien DNS dari Microsoft menarik garis yang sama antara menyelesaikan ruang nama internal dan meneruskan kueri publik ke atas, dan itulah susunan yang harus dipertahankan saat VPN diperkenalkan.

Jika kegagalan hanya lambat dan bukan gagal, pisahkan tundaan dari diagnosis. Tenggang waktu selama penemuan dapat berasal dari pengendali yang tak terjangkau, porta yang diblokir, atau penyelesai yang menjawab terlambat, dan tak satu pun terbukti hanya oleh penantian. Catat kueri sebenarnya, jawabannya, dan upaya koneksi sebelum Anda mengubah pengaturan penyelesai.