AD საიტის რუკების შედგენა VPN კლიენტებისთვის დომენის კონტროლერის დამაგრების წინააღმდეგ

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

რას ცვლის სინამდვილეში თითოეული მიდგომა

ქვექსელის ობიექტი კატალოგის ჩანაწერია, რომელიც ამბობს, რომელ საიტს ეკუთვნის მისამართების დიაპაზონი. Active Directory მოდულთან და არსებულ საიტთან ერთად ოპერაცია იმდენად მცირეა, რომ წინასწარ დათვალიერება შეიძლება:

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

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

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

სად იმარჯვებს ქვექსელის რუკა

აუზის რუკის შედგენა ქსელურ მდებარეობას ერთხელ აღწერს, ყოველი კლიენტისთვის, რომელიც DC Locator-ს იყენებს. როცა აუზი ერთი /24-დან სამამდე იზრდება, მოდელი ორ ან სამ ობიექტში იცვლება და არა აპლიკაციების სიაში. ეს არის მთელი უპირატესობა და ის დიდია, როცა კლიენტების რაოდენობა თქვენს კონტროლქვეშ არ არის.

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

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

სად იმარჯვებს დამაგრება

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

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

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

აირჩიეთ სამი პირობით

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

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

შეამოწმეთ VPN კლიენტიდან და ცალკე შეინახეთ ხელშეკრულებები

სცადეთ რეალური დისტანციური გზიდან და არა LAN სამუშაო სადგურიდან, რომელიც უკვე საიტზეა. მნიშვნელოვანია მხოლოდ კლიენტის საკუთარი ხედვა:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

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

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