როუტერის OpenVPN პარამეტრები გადატვირთვის შემდეგ ბრუნდება: შეაკეთეთ გენერატორი

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

რატომ ახლდება რედაქტირებული ფაილი

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

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

ჩასვით დირექტივა იქ, სადაც სკრიპტი აშენებს ფაილს

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

sed -i '/daemon_mgr/i echo client-config-dir clientconfig >>/etc/openvpn/server.conf' /etc/init.d/vpn_openvpn.sh
grep -c client-config-dir /etc/openvpn/server.conf

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

შეაკეთეთ ფორმა, რომელმაც ესკაპირებული გასაღებები შეინახა

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

openssl dhparam -out dh2048.pem 2048
grep -n "BEGIN DH PARAMETERS" dh2048.pem

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

განახლებების შემდეგ ხელახლა შეამოწმეთ

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

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