OpenVPN ვერ პოულობს ca.crt-ს, მიუხედავად იმისა, რომ პროფილი იტვირთება

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

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

პროფილის გზა საბაზო დირექტორია არ არის

წარმოიდგინეთ პროცესი, რომელიც იწყება /tmp-ში და იღებს /etc/vpn/prod/tenant-a.ovpn-ს. ამ პროფილის შიგნით, ca ca.crt სტრიქონი მიუთითებს ფარდობით გზაზე. არაფერი პროფილის პოვნის არგუმენტში არ გადაწერს ამ სახელს, ამიტომ პროცესი ეძებს /tmp/ca.crt-ს და აცხადებს დაკარგულ ფაილს.

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

რას გამოყოფს სახელმძღვანელო: --config და --cd

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

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

სერვისი სხვაგან იწყება

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

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

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

ძიების შემდეგ: ნებართვები, chroot და sandbox

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

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

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

დაამტკიცეთ გასწორება საკუთარი გაშვებით

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

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

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