OpenVPN-ის მართვის სოკეტი: მართვის არხი და არა მეტრიკები

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

რწმენა და მისი ფასი

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

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

რას ფლობს სინამდვილეში მიღებული კლიენტი

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

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

საკუთარი სოკეტი და არა ღია

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

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

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

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

TCP-ზე გამოქვეყნება იგივე დიზაინი არ არის

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

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

გაშვების დამოკიდებულებები, რომლებიც არ გითხოვიათ

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

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

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

როგორ გამოიყურება მიღება

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

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