რომელი openvpn ბინარული ფაილი მუშაობს? შეამოწმეთ გაშვების გზა

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

დაიწყეთ იმ გზით, რომელსაც სერვისი უშვებს

ტერმინალი და systemd-ის ერთეული შესრულებად ფაილებს ერთნაირად არ წყვეტს. Shell ეძებს PATH-ში; ერთეული გზას ასახელებს, და drop-in გადაფარვებს შეუძლიათ მისი ჩანაცვლება იმ ფაილის შეხების გარეშე, რომელსაც კითხულობთ. სწორედ ეს განსხვავება ხსნის ამ ამოცანაში არსებული დაბნეულობის უმეტეს ნაწილს. ის ასევე განსაზღვრავს, რომელ ფაილს უნდა მიმართოს თქვენმა შეკეთებამ.

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

ჩაწერეთ გადაწყვეტილი გზა, სანამ რამეს შეცვლით.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

შეადარეთ ბრძანების სახელი სერვისის გზას

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

მთავარია იცოდეთ, რომელი მფლობელი უშვებს ტრაფიკს რომ ემსახურება. თუ ერთეული /usr/local/sbin/openvpn-wrapper-ს უშვებს, მაშინ როცა თქვენი shell /usr/sbin/openvpn-ს წყვეტს, მეორე ფაილის შეკეთება სერვისზე არაფერს ცვლის.

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

მიეცით პაკეტების მონაცემთა ბაზას საუბრის უფლება პაკეტის ფაილებზე

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

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

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

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

ჩაწერეთ მდგომარეობა შეკეთებამდე

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

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

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

დაადასტურეთ გაშვება, შემდეგ მოაშორეთ გარსი

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

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

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