ვის უნდა ეკუთვნოდეს მარშრუტები და DNS, როცა openfortivpn უკავშირდება?

მუშა openfortivpn სესიაში ოთხი ეტაპი ერთმანეთზეა დაწყობილი. კლიენტი ავთენტიფიკაციას გადის კარიბჭესთან და იწყებს TLS კავშირს, შემდეგ ამ კავშირის შიგნით უშვებს PPP-ს, შემდეგ იღებს მისამართსა და DNS ინფორმაციას, და ბოლოს იყენებს ჰოსტის მარშრუტებსა და resolver-ის პარამეტრებს. ყოველი ეტაპი შეიძლება ცოცხალი იყოს, სანამ შემდეგი არ არის, და ამიტომ არის „დაკავშირებული“ ასეთი მოლიპული სიტყვა მხარდაჭერის თემებში.

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

ოთხი ეტაპი, რომლებიც ერთ კავშირს ჰგავს

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

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

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

ვინ არედაქტირებს მარშრუტიზაციის ცხრილს

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

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

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

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

ვის ეკუთვნის DNS და resolver-ის ფაილი

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

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

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

უფლებები, მზადყოფნა და გადაცემა

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

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

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