Azure-ის კერძო DNS VPN-ზე: resolver-ის ბოლო წერტილი თუ forwarder
ორივე დიზაინი კერძო ზონებს გვირაბით პასუხობს. შეადარეთ მართული შემავალი ბოლო წერტილი forwarder VM-ს, შემდეგ კი შეამოწმეთ გზა, რომელიც ორივე შემთხვევაში უნდა არსებობდეს.
ლოკალური ქსელის სერვერი Azure VM-ს კერძო მისამართით აღწევს და მაინც ვერ ხსნის მის კერძო ჰოსტის სახელს, რაც ადამიანებს გატეხილი გვირაბის ძებნას აიძულებს. გვირაბი რიგზეა. რაც აკლია, DNS საზღვარია: ლოკალურ მხარეს არავინ იცის, რომ გარკვეულ Azure კერძო ზონას VNet-ის შიგნით მდებარე resolver-მა უნდა უპასუხოს. ორი დიზაინი ხურავს ამ ნაპრალს და ისინი განსხვავდებიან იმით, თუ რას მართავთ საბოლოოდ, და არა იმით, მუშაობს თუ არა მოთხოვნები.
გვირაბი მოთხოვნებს გადააქვს, არა ზონების ცოდნას
Site-to-site კავშირი პაკეტებს ორ ქსელს შორის მარშრუტს აძლევს. ის ლოკალურ DNS სერვერს არ ეუბნება, რომელი სახელების სივრცე ეკუთვნის Azure-ს ან რომელმა მისამართმა უნდა უპასუხოს, ამიტომ მოთხოვნა ან ინტერნეტში მიდის და ცარიელი ბრუნდება, ან ლოკალურ resolver-ს არასდროს ტოვებს.
გამოსწორებას ორი ნახევარი აქვს, რომელთა გამოყოფაც ადვილია. ერთი ნახევარი VNet-ის შიგნით მდებარე resolver-ია, რომელიც გვირაბიდან მოსულ მოთხოვნებს იღებს. მეორე ლოკალურ მხარეს არსებული პირობითი forwarder-ია, რომელიც ზუსტად ერთ სახელთა სივრცეს უგზავნის ამ resolver-ს. არც ერთი ნახევარი ცალკე არ მუშაობს.
დავუშვათ, რომ ზონა cloud.corp.example-ია ამ აღწერის დარჩენილი ნაწილისთვის, და ყველა მისამართი საილუსტრაციოდ მიიჩნიეთ.
ვარიანტი A: მართული შემავალი ბოლო წერტილი
Azure DNS Private Resolver გთავაზობთ შემავალ ბოლო წერტილს, რომელიც VNet-ის გარედან მოსულ DNS მოთხოვნებს იღებს. თქვენ მას სპეციალურ დელეგირებულ ქვექსელში ათავსებთ, კერძო ზონას ამ VNet-ზე აკავშირებთ და იწერთ შემავალ მისამართს, რომელსაც სერვისი ანიჭებს.
შემდეგ ლოკალურ DNS სერვერზე ქმნით პირობით forwarder-ს ზუსტი სახელთა სივრცისთვის ამ მისამართისკენ:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft-ის ჰიბრიდული DNS პროცედურა აღწერს როგორც ზონის კავშირს, ისე forwarder-ის ნაბიჯს. მართული გზა არ გიტოვებთ გასაპატჩ DNS პროგრამულ უზრუნველყოფას, და ბოლო წერტილის მისამართი სტაბილური რჩება რესურსის მთელი სიცოცხლის განმავლობაში.
ფასი ისაა, რომ ახლა თქვენ გაქვთ resolver რესურსი, მისი ქვექსელის დელეგირება და მისი ხარჯი, რაც რეალურია მაშინაც, როცა მოთხოვნების მოცულობა ძალიან მცირეა.
ვარიანტი B: forwarder VM VNet-ის შიგნით
უფრო ძველი დიზაინი DNS პროგრამულ უზრუნველყოფას VNet-ის ჩვეულებრივ VM-ზე ამუშავებს: Windows DNS, BIND ან dnsmasq, კერძო ზონა კი ან ლოკალურად ინახება, ან გადაეცემა 168.63.129.16-ზე მდებარე Azure resolver-ს. ლოკალური პირობითი forwarder ამ VM-ის კერძო მისამართზე მიუთითებს.
ეს ვარიანტი ნაცნობია გუნდებისთვის, რომლებიც უკვე მართავენ DNS სერვერებს, და მას შეუძლია დამატებითი ლოგიკა ატაროს, მაგალითად ლოგირება ან split-horizon პასუხები. ის ასევე მემკვიდრეობით იღებს DNS სერვერის ყველა ოპერაციულ ვალდებულებას: პატჩინგი, მეორე ინსტანცია ხელმისაწვდომობისთვის, მონიტორინგი და აღდგენის გზა, როცა VM იცვლება და მისი მისამართი იცვლება.
ჩვეულებრივი VNet ჰოსტი DNS პროქსი არაა, სანამ სერვისი არ დამონტაჟდება და ნებართვას არ მიიღებს ამ კლიენტებზე პასუხის გასაცემად, და სწორედ ამ ნაბიჯს გამოტოვებენ ადამიანები VM-ის კლონირებისას.
რომელი შეესაბამება თქვენს ოპერაციას
შედარება არ არის იმაზე, რომელი დიზაინი უფრო სწრაფია. ის არის იმაზე, გსურთ თუ არა საერთოდ DNS პროგრამული უზრუნველყოფის მართვა, და ამართლებს თუ არა მოთხოვნების მოცულობა ისეთ მართულ რესურსს, რომელიც ბოლო წერტილისა და მოთხოვნის მიხედვით ითვლის ტარიფს.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
რომელი სტრიქონიც არ უნდა გადაწყვიტოს, ლოკალური forwarder-ის წესი ერთნაირად გამოიყურება. სწორედ ეს ნაწილი უნდა არსებობდეს ორივე დიზაინში და სწორედ ეს ნაწილი აკლია ყველაზე ხშირად, როცა ვინმე ამბობს, რომ გადაწყვეტა Azure-ის შიგნიდან მუშაობს, ოფისიდან კი არა.
შეამოწმეთ გზა თანმიმდევრობით
დაადასტურეთ, რომ ზონა დაკავშირებულია VNet-ზე, რომელიც resolver-ს შეიცავს, და რომ ლოკალური forwarder სახელთა სივრცეს ასახელებს და არა მშობელ დომენს. corp.example-ისთვის forwarder არ დაემთხვევა cloud.corp.example-ს, თუ resolver თავად არ დელეგირებს, და ეს შეუსაბამობა სუფთა უარყოფით პასუხს იძლევა, რომელიც დაკარგულ ჩანაწერს ჰგავს.
შემდეგ შეამოწმეთ, რომ მოთხოვნა ბოლო წერტილამდე აღწევს: ლოკალურ წყაროს resolver-ის მისამართამდე მარშრუტი და დაბრუნების გზა სჭირდება, და 53 პორტი UDP-ითაც და TCP-ითაც უნდა იყოს დაშვებული იქ, სადაც პოლიტიკა იძლევა საშუალებას. NSG ვერ მოგცემთ დაკარგულ ზონის ჩანაწერს, და სწორი ზონა ვერ უპასუხებს მოთხოვნას, რომელიც არასდროს აღწევს.
დიაგნოსტიკისას სთხოვილი FQDN შეინახეთ არჩეული resolver-ის გვერდით, და გამოაცალკევეთ დროის ამოწურვა უარყოფითი პასუხისგან. დროის ამოწურვა გზის ან პოლიტიკის პრობლემაა. უარყოფითი პასუხი ნიშნავს, რომ მოთხოვნა მივიდა და სახელთა სივრცე არ დაემთხვა. სამუშაოს რიგი: დაუკავშირეთ ზონა, დაამატეთ პირობითი forwarder, გახსენით 53 პორტი ორივე მიმართულებით, გამოსცადეთ ერთი სახელი ლოკალური მხრიდან, და მხოლოდ ამის შემდეგ შეხედეთ აპლიკაციის საკუთარ ავტორიზაციას.