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

ორი კანდიდატი სხვადასხვა რამეს ფლობს

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

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

QuestionSupported config sourcePost-generation script
Survives a GUI saveYesOnly if the save does not regenerate the file
Survives a package upgradeUsually, when the field is documentedNo guarantee; the wrapper can be replaced
Supportable by the vendorYesNo
Obvious to the next adminYes, it is in the UINo, it lives in a wrapper

რას აწარმოებს მოწყობილობა ხელახლა, და როდის

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

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

რა უნდა გამოხატოს მხარდაჭერილმა მფლობელმა

ფილიალის პრეფიქსს სამი განცხადება სჭირდება და არა ერთი. კლიენტმა უნდა ისწავლოს მარშრუტი, სერვერმა უნდა იცოდეს რომელი ავთენტიფიცირებული კლიენტი ფლობს პრეფიქსს, და ფილიალის მხარემ ტრაფიკი უნდა დააბრუნოს მისთვის მიცემულ გვირაბის მისამართზე. OpenVPN-ის ტერმინებში ეს ნიშნავს გაგზავნილ route-ს, კლიენტზე მიბმულ შესაბამის iroute-ს და დაბრუნების გზას მეორე მხარეს.

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

როცა მხარდაჭერილი მართვა არ არსებობს

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

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

გახადეთ განზრახვა აუდიტირებადი

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

როცა რაღაც ფუჭდება, შეადარეთ გენერირებული შედეგი იმ ჩანაწერს, ნაცვლად იმისა, რომ აუხსნელი ხაზი აღადგინოთ და იმედი გქონდეთ.OpenVPN 2.6-ის ცნობარი არის ადგილი, სადაც ინტერფეისთან კამათამდე დაადასტურებთ, როგორ ურთიერთქმედებენ route და iroute.

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

დაკავშირებული სტატიები