ორი VPN, ერთი გადამწყვეტი: იმარჯვებს ის, ვინც ბოლოს დაწერა

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

მითი: უახლესი VPN ფლობს DNS-ს

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

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

დააკავშირეთ სახელების სივრცეები გადამწყვეტებთან

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

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

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

შეინახეთ ჩატვირთვის გზა

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

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

გადაფარებული მისამართები DNS-ის პრობლემა არ არის

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

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

დაამტკიცეთ ეს რეალური აპლიკაციებით

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

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