status=200/CHDIR: systemd-მა OpenVPN არასოდეს გაუშვა

CHDIR შეცდომა ნიშნავს, რომ systemd-მა კატალოგში ვერ შეძლო შესვლა და არა ის, რომ OpenVPN-მა პროფილი ვერ წაიკითხა. წაიკითხეთ unit, სანამ VPN-ის კონფიგურაციას შეეხებით.

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

წაიკითხეთ სტატუსის კოდი აპლიკაციამდე

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

ეს განსხვავება მნიშვნელოვანია, რადგან შესწორებები სხვადასხვა ფაილშია. CHDIR შეცდომა ეხება ბილიკს და იმას, როგორ ხედავს მას სერვისი. Exec შეცდომა ეხება ბინარულ ფაილს, მის ინტერპრეტატორს ან დაუკავშირებელ mount-ს. VPN-ის დისტანციური წერტილის, შიფრების სიის ან სერტიფიკატის ბილიკის შეცვლა არც ერთს არ გამოასწორებს.

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

ჰკითხეთ unit-ს, სად უნდა იყოს

წაიკითხეთ ეფექტური unit და არა ის ფაილი, რომელიც ფიქრობთ რომ დაინსტალირებულია, რადგან drop-in-ები შეიძლება გადაფარონ სამუშაო კატალოგი ისე, რომ ძირითადი unit არასოდეს შეცვალოთ. Show-ის გამომავალი პირდაპირ პასუხობს კითხვას:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

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

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

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

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

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

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

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

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

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

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

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

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

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