İctimai DNS işləyir, amma bu Active Directory-nin tapıldığı demək deyil

VPN qoşulur, brauzer ictimai sayt açır, noutbuk isə hələ də domenə daxil ola bilmir. Adi nəticə budur ki, adlar həll olunduğu üçün DNS qaydasındadır. O, qaydasında deyil və səbəb budur ki, brauzer testi domenə qoşulmuş müştərinin ehtiyac duyduğu zəncirdən yalnız bir sorğunu yoxlayır. Domen kəşfi əvvəlcə xidmət qeydlərini, sonra həmin qeydlərin adlandırdığı nəzarətçilərin ünvanlarını, sonra isə həmin nəzarətçilərin dinlədiyi portlara marşrutu istəyir. İctimai cavab bu addımların heç birini təmin etmir.

Mif: adlar həll olunur, deməli DNS bitib

İctimai saytın həll olunması sizə yalnız onu deyir ki, hansısa həlledici ictimai zonadakı ad üçün bir A və ya AAAA sorğusuna cavab verib. Active Directory eyni protokolu başqa sual üçün istifadə edir: domenin xidmətləri haradadır və bu müştəri hansı nəzarətçidən istifadə etməlidir. Sual domenin adını daşıyan zona altında SRV qeydləri kimi ifadə olunur və rekursiv ictimai həlledicinin onları saxlamağa heç bir səbəbi yoxdur.

Qeyd yox olduqda həlledici mənfi cavab qaytarır, bu da kəsinti deyil, etibarlı DNS cavabıdır. Sonra müştəri varsa keşlənmiş nəzarətçi məlumatına keçir və bu, masaüstü kompüterin saatlarla yaxşı görünüb yenidən başlatmadan və ya parol dəyişikliyindən sonra uğursuz olmasının dəqiq səbəbidir.

Domen müştərisi əslində nə soruşur, sıra ilə

corp.example kimi bir domen üçün ümumi lokator sorğusu _ldap._tcp.dc._msdcs.corp.example olur. SRV cavabları namizəd nəzarətçiləri və onların portlarını adlandırır, sonra müştəri bağlantı açmazdan əvvəl həmin host adları üçün ünvan qeydlərinə ehtiyac duyur. Saytı nəzərə alan kəşf sayt alt domeni altında sorğular əlavə edir və cavablar hansı nəzarətçilərin üstün tutulduğunu, hansının məcburi olduğunu deyil, müəyyən edir.

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

Zənciri bu sıra ilə, problemin baş verdiyi şəbəkədən izləyin. Əlçatmaz ünvana həll olunan host adı marşrut uğursuzluğudur, DNS uğursuzluğu deyil. Lokator qeydləri çatışmayan əlçatan nəzarətçi DNS uğursuzluğudur, marşrut uğursuzluğu deyil. İkisi oxşar istifadəçi şikayətləri və tamamilə fərqli təmir yolları yaradır.

Nə üçün ictimai həlledici cavab verir və giriş yenə pozulur

Adapter müştəriyə ictimai həlledici verirsə, ictimai adlar işləyir, daxili ad məkanı isə işləmir. İkinci ictimai həlledici əlavə etmək kömək etmir, çünki heç biri zonanı saxlamır. “Əvvəl daxili, sonra ictimai” kimi tanınan siyahı da hər domen üçün qayda kimi davranmır: birinci serverdən gələn mənfi cavab qanuni cavabdır və müştəri yalnız cavab boş olduğu üçün ikinci serveri yenidən sınamır.

İki daxili həlledici, əgər ikisini işlədirsinizsə, AD ad məkanını saxlamalı və müştərinin cari şəbəkəsindən əlçatan olmalıdır. Bölünmüş tunel dizaynlarının pozduğu hissə budur: VPN tunel alt şəbəkəsini daşıya bilər, daxili həlledici isə tunelin marşrutlaşdırmadığı prefiksdə yerləşir, beləliklə sorğu ona cavab verə bilməyən həllediciyə çıxır.

Windows həmçinin xüsusi ad məkanlarını xüsusi serverlərə yönəldə bilən ad həlli siyasəti tətbiq edir və adapterin göstərdiyi DNS ünvanları bütün hekayə deyil. Adapter siyahısını həmin siyasəti dəyişmədən dəyişmək effektiv konfiqurasiyanı toxunulmaz qoya bilər və buna görə tətbiq olunmuş görünən düzəlişin heç bir təsiri olmur.

Tunelin DNS-i ilə marşrutlarını uyğun saxlayın

Həlledici göndərən, amma onu ehtiva edən prefiksi göndərməyən VPN profili müştərinin çata bilmədiyi həlledici yaradır; prefiksi göndərib həlledici göndərməyən profil isə müştərini yerli həlledicidən soruşmağa qoyur. Cütü bir konfiqurasiya elementi kimi qəbul edin və hər profil dəyişikliyindən sonra hər ikisini yoxlayın, çünki sırası dəyişmiş göndərmə və ya yeni bölünmüş tunel siyasəti onları ayıra bilər.

Müştərinin göndərilən parametrlə nə etdiyini də yoxlayın. Bəzi müştərilər DNS serverini yalnız tunel interfeysinə tətbiq edir və fiziki adapterin həlledicisini yerində qoyur, buna görə hansının qalib gəlməsi interfeys metrikasından və soruşulan addan asılıdır. Daxili cavab yalnız fiziki adapter söndürüldükdə gəlirsə, düzəldilməli mexanizm budur, domen qeydləri deyil.

Kəşf çağırışı və bir canlı əməliyyatla qəbul edin

Faydalı qəbul testi lokator sorğusunu işlədir və sonra bir real autentifikasiyalı əməliyyat yerinə yetirir, məsələn kataloqla dəstəklənən paylaşmanı açmaq və ya bilet tələb etmək. Bunu VPN keçidindən əvvəl və sonra yenidən, eyni maşında, aralarında yenidən başlatma olmadan edin. Keşlənmiş etimadnamələr və artıq açıq sessiyalar pozulmuş yolu məmnuniyyətlə sağlam göstərəcək, buna görə uğurlu masaüstü girişi test deyil.

Microsoft-un DNS müştəri tövsiyələri daxili ad məkanının həlli ilə ictimai sorğuların yuxarıya ötürülməsi arasında eyni xətti çəkir və VPN tətbiq edildikdə qorunmalı olan düzən budur.

Uğursuzluq yalnız yavaşdırsa, gecikməni diaqnozdan ayrı saxlayın. Kəşf zamanı fasilə əlçatmaz nəzarətçidən, bloklanmış portdan və ya gec cavab verən həlledicidən gələ bilər və bunların heç biri tək gözləmə ilə sübut olunmur. Həlledici parametrini dəyişməzdən əvvəl faktiki sorğunu, onun cavabını və bağlantı cəhdini qeyd edin.