კლიენტის კაუჭი თუ სერვერის კაუჭი? სად მუშაობს OpenVPN-ის სკრიპტი

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

ორი მანქანა, ორი კითხვა, რომლებზეც ჯერ პასუხი უნდა გაეცეს

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

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

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

სერვერის მხარის ვარიანტი: მოვლენა ყოველ კავშირზე

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

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

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

კლიენტის მხარის ვარიანტი: სამუშაო, რომელიც ლოკალურად უნდა შესრულდეს

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

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

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

რატომ არ არის გაშვებადი კოდის push სიაში

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

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

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

რა უნდა გადაამოწმოთ, სანამ რომელიმე კაუჭს ენდობით

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

გამოსცადეთ იმ ანგარიშის ქვეშ, რომელიც ნამდვილად შეასრულებს მას, იმ მომენტში, როცა ის ნამდვილად შესრულდება. openvpn(8) სახელმძღვანელო აღწერს ორივე კაუჭის ოჯახს და push-ის შეზღუდვებს; პლატფორმა, რომელზეც აწყობთ, აღწერს, საერთოდ გთავაზობთ თუ არა ისინი. სკრიპტი, რომელიც ინტერაქტიულ ადმინისტრატორის ტერმინალში წარმატებით სრულდება, ჰიპოთეზაა და არა გადამოწმება.