VPN-ის საბოლოო წერტილის სახელი და კერძო სერვისის სახელი: ორი მფლობელი

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

დაასახელეთ ორივე ჩანაწერი, სანამ რომელიმეს გამართავთ

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

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

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

საბოლოო წერტილი უნდა გაიხსნას ნებისმიერი გვირაბის არსებობამდე

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

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

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

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

სერვისის სახელი აღწერს, სად ცხოვრობს აპლიკაცია

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

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

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

შეამოწმეთ ორი გზა ცალკე

შეამოწმეთ საბოლოო წერტილი გვირაბის გარედან, სერვისი კი შიგნიდან, და შეინახეთ შედეგები როგორც ორი დამოუკიდებელი ფაქტი:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

გაუშვით წყვილი ყოველი მისამართის ცვლილების შემდეგ და აღნიშნეთ, რომელი ჩანაწერი გადაადგილდა. გადაცემა, რომელიც მხოლოდ ამბობს «DNS განახლდა», შემდეგ ინჟინერს აგრძნობინებს, რომელმა სასიცოცხლო ციკლმა იმუშავა სინამდვილეში.