საჯარო DNS-ის მუშაობა არ ნიშნავს, რომ Active Directory მოიძებნება

VPN უკავშირდება, ბრაუზერი ხსნის საჯარო საიტს, და ლეპტოპი მაინც ვერ შედის დომენში. ჩვეულებრივი დასკვნაა, რომ DNS რიგზეა, რადგან სახელები იხსნება. ის რიგზე არ არის, და მიზეზი ის არის, რომ ბრაუზერის ტესტი ამოწმებს მხოლოდ ერთ მოთხოვნას იმ ჯაჭვიდან, რომელიც დომენზე მიერთებულ კლიენტს სჭირდება. დომენის აღმოჩენა ჯერ სერვისის ჩანაწერებს ითხოვს, შემდეგ იმ კონტროლერების მისამართებს, რომლებსაც ეს ჩანაწერები ასახელებენ, და ბოლოს მარშრუტს იმ პორტებამდე, რომლებზეც ეს კონტროლერები უსმენენ. საჯარო პასუხი ამ ნაბიჯებიდან არცერთს არ აკმაყოფილებს.

მითი: სახელები იხსნება, ასე რომ DNS დამთავრებულია

საჯარო საიტის ამოხსნა მხოლოდ იმას ამბობს, რომ რომელიღაც ამომხსნელმა უპასუხა ერთ A ან AAAA მოთხოვნას საჯარო ზონაში არსებულ სახელზე. Active Directory იმავე პროტოკოლს სხვა კითხვისთვის იყენებს: სად არიან დომენის სერვისები და რომელი კონტროლერი უნდა გამოიყენოს ამ კლიენტმა. კითხვა გამოიხატება როგორც SRV ჩანაწერები დომენის სახელობის ზონის ქვეშ, და რეკურსიულ საჯარო ამომხსნელს მათი შენახვის მიზეზი არ აქვს.

როცა ჩანაწერი აკლია, ამომხსნელი უარყოფით პასუხს აბრუნებს, რაც ვალიდური DNS პასუხია და არა შეწყვეტა. შემდეგ კლიენტი უბრუნდება ქეშირებულ კონტროლერის ინფორმაციას, თუ აქვს, და სწორედ ამიტომ შეიძლება სამუშაო მაგიდა საათობით კარგად გამოიყურებოდეს და ჩავარდეს გადატვირთვის ან პაროლის შეცვლის შემდეგ.

რას ითხოვს დომენის კლიენტი სინამდვილეში, თანმიმდევრობით

corp.example-ის მსგავსი დომენისთვის ზოგადი ლოკატორის მოთხოვნა _ldap._tcp.dc._msdcs.corp.example-ია. SRV პასუხები ასახელებენ კანდიდატ კონტროლერებს და მათ პორტებს, შემდეგ კლიენტს სჭირდება მისამართის ჩანაწერები ამ ჰოსტის სახელებისთვის, სანამ კავშირს გახსნის. საიტზე ორიენტირებული აღმოჩენა ამატებს მოთხოვნებს საიტის ქვედომენის ქვეშ, და პასუხები განსაზღვრავენ, რომელი კონტროლერები არიან სასურველი და არა რომელი სავალდებულო.

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

მიჰყევით ჯაჭვს ამ თანმიმდევრობით, იმ ქსელიდან, სადაც პრობლემა ჩნდება. ჰოსტის სახელი, რომელიც მიუწვდომელ მისამართზე იხსნება, მარშრუტიზაციის ხარვეზია და არა DNS ხარვეზი. მისაწვდომი კონტროლერი, რომელსაც ლოკატორის ჩანაწერები აკლია, DNS ხარვეზია და არა მარშრუტიზაციის ხარვეზი. ორივე ერთნაირი მომხმარებლის ჩივილებს და სრულიად განსხვავებულ შეკეთებებს იძლევა.

რატომ პასუხობს საჯარო ამომხსნელი და შესვლა მაინც ფუჭდება

თუ ადაპტერი კლიენტს საჯარო ამომხსნელს აძლევს, საჯარო სახელები მუშაობს და შიდა სახელების სივრცე არა. მეორე საჯარო ამომხსნელის დამატება არ ეხმარება, რადგან არც ერთი არ ფლობს ზონას. არც ჩვეულებრივი სია „ჯერ შიდა, შემდეგ საჯარო“ იქცევა როგორც წესი თითოეული დომენისთვის: პირველი სერვერის უარყოფითი პასუხი ლეგიტიმური პასუხია, და კლიენტი მეორე სერვერს ხელახლა არ სცდის მხოლოდ იმიტომ, რომ პასუხი ცარიელი იყო.

ორივე შიდა ამომხსნელი, თუ ორს ამუშავებთ, უნდა ფლობდეს AD-ის სახელების სივრცეს და იყოს მისაწვდომი კლიენტის მიმდინარე ქსელიდან. სწორედ ამას ამტვრევს გაყოფილი გვირაბის დიზაინები: VPN შეიძლება ატარებდეს გვირაბის ქვექსელს, სანამ შიდა ამომხსნელი იჯდება პრეფიქსზე, რომელსაც გვირაბი არ მარშრუტიზებს, ამიტომ მოთხოვნა გადის ამომხსნელთან, რომელიც მას ვერ უპასუხებს.

Windows ასევე იყენებს სახელების ამოხსნის პოლიტიკას, რომელსაც შეუძლია კონკრეტული სახელების სივრცეები კონკრეტულ სერვერებზე მიმართოს, და ადაპტერის მიერ ნაჩვენები DNS მისამართები მთელი ისტორია არ არის. ადაპტერის სიის შეცვლა ამ პოლიტიკის შეცვლის გარეშე შეიძლება ეფექტური კონფიგურაცია უხელშეხებელი დატოვოს, და ამიტომ გამოყენებულად მოჩვენებულ შესწორებას არავითარი ეფექტი არ აქვს.

შეინარჩუნეთ გვირაბის DNS და მისი მარშრუტები შეთანხმებული

VPN პროფილი, რომელიც ამომხსნელს უგზავნის, მაგრამ არა მის შემცველ პრეფიქსს, ქმნის ამომხსნელს, რომელსაც კლიენტი ვერ მიაღწევს; ერთი, რომელიც პრეფიქსს უგზავნის ამომხსნელის გარეშე, კლიენტს ლოკალურს აკითხებინებს. მოეპყარით წყვილს როგორც ერთ კონფიგურაციის ერთეულს და შეამოწმეთ ორივე ყოველი პროფილის ცვლილების შემდეგ, რადგან გადალაგებულმა გაგზავნამ ან გაყოფილი გვირაბის ახალმა პოლიტიკამ შეიძლება ისინი გააცალკევოს.

შეამოწმეთ ასევე, რას აკეთებს კლიენტი გაგზავნილი პარამეტრით. ზოგი კლიენტი DNS სერვერს მხოლოდ გვირაბის ინტერფეისზე იყენებს და ფიზიკური ადაპტერის ამომხსნელს ადგილზე ტოვებს, ამიტომ რომელი იმარჯვებს, დამოკიდებულია ინტერფეისის მეტრიკასა და მოთხოვნილ სახელზე. თუ შიდა პასუხი მხოლოდ მაშინ მოდის, როცა ფიზიკური ადაპტერი გამორთულია, სწორედ ის მექანიზმია შესაკეთებელი და არა დომენის ჩანაწერები.

მიიღეთ აღმოჩენის გამოძახებით და ერთი ცოცხალი ოპერაციით

სასარგებლო მიღების ტესტი უშვებს ლოკატორის მოთხოვნას და შემდეგ ასრულებს ერთ რეალურ ავთენტიფიცირებულ ოპერაციას, მაგალითად ხსნის კატალოგზე დაფუძნებულ გაზიარებას ან ითხოვს ბილეთს. გააკეთეთ ეს VPN-ის გადასვლამდე და კიდევ ერთხელ მის შემდეგ, იმავე მანქანაზე, შუალედური გადატვირთვის გარეშე. ქეშირებული სერტიფიკატები და უკვე გახსნილი სესიები სიამოვნებით გახდიან გატეხილ გზას ჯანსაღად, ამიტომ წარმატებული სამუშაო მაგიდის შესვლა ტესტი არ არის.

Microsoft-ის რეკომენდაციები DNS კლიენტისთვის იმავე ზღვარს ავლებენ შიდა სახელების სივრცის ამოხსნასა და საჯარო მოთხოვნების ზემოთ გადაცემას შორის, და ეს არის ის წყობა, რომელიც უნდა შენარჩუნდეს VPN-ის შემოღებისას.

თუ ხარვეზი მხოლოდ ნელია და არა ჩავარდნილი, შეინახეთ შეყოვნება დიაგნოზისგან ცალკე. აღმოჩენის დროს დროის ამოწურვა შეიძლება მოვიდეს მიუწვდომელი კონტროლერიდან, დაბლოკილი პორტიდან ან დაგვიანებით პასუხობს ამომხსნელიდან, და არც ერთი მათგანი მხოლოდ ლოდინით არ მტკიცდება. ჩაიწერეთ რეალური მოთხოვნა, მისი პასუხი და კავშირის მცდელობა, სანამ ამომხსნელის პარამეტრს შეცვლით.