DNS awam berfungsi bukan bermakna Active Directory boleh ditemui

VPN bersambung, pelayar membuka laman awam, dan komputer riba masih tidak dapat log masuk ke domain. Kesimpulan biasa ialah DNS elok kerana nama diselesaikan. Ia tidak elok, dan puncanya ialah ujian pelayar hanya menjalankan satu carian daripada rantaian yang diperlukan oleh klien yang disertai domain. Penemuan domain meminta rekod perkhidmatan dahulu, kemudian alamat pengawal yang dinamakan oleh rekod itu, kemudian laluan ke port yang didengar oleh pengawal tersebut. Jawapan awam tidak memenuhi satu pun daripada langkah itu.

Mitos: nama diselesaikan, jadi DNS sudah selesai

Laman awam yang diselesaikan hanya memberitahu bahawa sesuatu penyelesai menjawab satu pertanyaan A atau AAAA bagi nama dalam zon awam. Active Directory menggunakan protokol yang sama untuk soalan lain: di mana perkhidmatan domain, dan pengawal mana yang patut digunakan oleh klien ini. Soalan itu dinyatakan sebagai rekod SRV di bawah zon yang dinamakan sempena domain, dan penyelesai awam rekursif tiada sebab untuk menyimpannya.

Apabila rekod itu tiada, penyelesai memulangkan jawapan negatif, yang merupakan jawapan DNS yang sah dan bukan gangguan. Klien kemudian kembali kepada maklumat pengawal dalam cache jika ada, dan itulah sebabnya komputer meja boleh kelihatan elok berjam-jam dan gagal selepas but semula atau pertukaran kata laluan.

Apa yang sebenarnya diminta oleh klien domain, mengikut urutan

Bagi domain seperti corp.example, pertanyaan pencari generik ialah _ldap._tcp.dc._msdcs.corp.example. Jawapan SRV menamakan calon pengawal dan port mereka, kemudian klien memerlukan rekod alamat bagi nama hos itu sebelum boleh membuka sambungan. Penemuan yang sedar tapak menambah pertanyaan di bawah subdomain tapak, dan jawapannya menentukan pengawal mana yang diutamakan, bukan mana yang wajib.

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

Ikuti rantaian itu mengikut urutan tersebut, dari rangkaian tempat masalah berlaku. Nama hos yang diselesaikan ke alamat tidak boleh dicapai ialah kegagalan penghalaan, bukan kegagalan DNS. Pengawal yang boleh dicapai tetapi rekod pencarinya tiada ialah kegagalan DNS, bukan kegagalan penghalaan. Kedua-duanya menghasilkan aduan pengguna yang serupa dan pembaikan yang sama sekali berbeza.

Mengapa penyelesai awam menjawab tetapi log masuk masih rosak

Jika penyesuai memberikan penyelesai awam kepada klien, nama awam berfungsi dan ruang nama dalaman tidak. Menambah penyelesai awam kedua tidak membantu, kerana kedua-duanya tidak memegang zon itu. Senarai lazim “dalaman dahulu, awam kemudian” juga tidak berkelakuan seperti peraturan bagi setiap domain: jawapan negatif daripada pelayan pertama ialah jawapan yang sah, dan klien tidak mencuba pelayan kedua semula semata-mata kerana jawapannya kosong.

Kedua-dua penyelesai dalaman, jika anda menjalankan dua, mesti memegang ruang nama AD dan boleh dicapai dari rangkaian semasa klien. Itulah bahagian yang dirosakkan oleh reka bentuk terowong berpecah: VPN boleh membawa subnet terowong manakala penyelesai dalaman berada pada awalan yang tidak dihalakan oleh terowong, jadi pertanyaan keluar kepada penyelesai yang tidak dapat menjawabnya.

Windows juga menggunakan dasar penyelesaian nama yang boleh mengarahkan ruang nama tertentu kepada pelayan tertentu, dan alamat DNS yang dipaparkan oleh penyesuai bukanlah keseluruhan cerita. Menukar senarai penyesuai tanpa menukar dasar itu boleh membiarkan konfigurasi berkesan tidak tersentuh, dan itulah sebabnya pembaikan yang kelihatan digunakan tidak memberi kesan.

Kekalkan DNS terowong dan laluannya selaras

Profil VPN yang menolak penyelesai tetapi bukan awalan yang mengandunginya mencipta penyelesai yang tidak dapat dicapai oleh klien; profil yang menolak awalan tanpa penyelesai membiarkan klien bertanya kepada yang tempatan. Anggap pasangan itu sebagai satu item konfigurasi dan periksa kedua-duanya selepas setiap perubahan profil, kerana tolakan yang disusun semula atau dasar terowong berpecah yang baharu boleh memisahkan keduanya.

Periksa juga apa yang klien lakukan dengan tetapan yang ditolak itu. Sesetengah klien menggunakan pelayan DNS hanya pada antara muka terowong dan membiarkan penyelesai penyesuai fizikal di tempatnya, jadi mana yang menang bergantung pada metrik antara muka dan nama yang ditanya. Jika jawapan dalaman hanya datang apabila penyesuai fizikal dilumpuhkan, itulah mekanisme yang perlu dibaiki, bukan rekod domain.

Terima dengan panggilan penemuan dan satu operasi langsung

Ujian penerimaan yang berguna menjalankan pertanyaan pencari dan kemudian melakukan satu operasi disahkan sebenar, seperti membuka perkongsian yang disokong direktori atau meminta tiket. Lakukan sebelum peralihan VPN dan sekali lagi selepasnya, pada mesin yang sama, tanpa but semula di antaranya. Kelayakan dalam cache dan sesi yang sudah terbuka akan dengan senang hati membuat laluan rosak kelihatan sihat, jadi log masuk meja yang berjaya bukanlah ujiannya.

Syor Microsoft untuk klien DNS menarik garis yang sama antara menyelesaikan ruang nama dalaman dan memajukan pertanyaan awam ke atas, dan itulah susunan yang perlu dikekalkan apabila VPN diperkenalkan.

Jika kegagalan hanya lambat dan bukan gagal, asingkan kelewatan daripada diagnosis. Tamat masa semasa penemuan boleh datang daripada pengawal yang tidak boleh dicapai, port yang disekat atau penyelesai yang menjawab lewat, dan tiada satu pun daripadanya dibuktikan oleh penantian semata-mata. Rakam pertanyaan sebenar, jawapannya dan percubaan sambungan sebelum anda menukar tetapan penyelesai.