OpenVPN-ის DNS რჩება SIGKILL-ის შემდეგ: ჯერ მფლობელი შეამოწმეთ

DNS წყვეტს გადაწყვეტას მას შემდეგ, რაც OpenVPN-ის კლიენტი მოკლულია, და პირველი იმპულსია /etc/resolv.conf გადაწერა. ამ ცვლილებამ შეიძლება გატეხოს მომუშავე რეზოლვერი, მაშინ როცა ნამდვილი მოძველებული მდგომარეობა სხვაგანაა. პირველ რიგში გასარკვევი კითხვაა, ვინ ფლობს ტუნელის მიერ დაყენებულ DNS პარამეტრებს და ჰქონდა თუ არა მნიშვნელობა გასვლას, რომელმაც გაწმენდა გამოტოვა.

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

გადაწყვიტეთ რა სახის გასვლა მოხდა

Community გამოცემაში OpenVPN-ისთვის როგორც SIGINT, ისე SIGTERM ნაზი გასვლის მოთხოვნებია. SIGKILL-ის დაჭერა შეუძლებელია: მისი დაბლოკვა ან დამუშავება არ შეიძლება, ამიტომ არცერთ გამორთვის რუტინას არ ეძლევა შესრულების შანსი. ჩვეულებრივი Ctrl+C წინა პლანზე მყოფ ტერმინალში წარმოქმნის SIGINT-ს, ხოლო ლოდინის შეწყვეტილი ზედამხედველი ჩვეულებრივ SIGKILL-მდე ადის. განსხვავება მნიშვნელოვანია, რადგან მხოლოდ მეორე შემთხვევა იძლევა გარანტიას, რომ კაუჭები გამოტოვებულია.

screen-ის ან tmux-ის შიგნით გაშვება არ ცვლის, რომელ სიგნალს აგზავნის Ctrl+C. შეამოწმეთ რა მიიღო პროცესმა სინამდვილეში და არა რას აკეთებს ჩვეულებრივ ტერმინალი.

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

გადაწყვიტეთ ვინ ფლობს რეზოლვერს

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

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

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

რა შეუძლია და რა არ შეუძლია down კაუჭს

სკრიპტი down ერთხელ სრულდება მას შემდეგ, რაც TUN/TAP მოწყობილობა დაიხურა. down-pre-ის დამატება ამ რიგს აბრუნებს და სკრიპტს ასრულებს მაშინ, როცა მოწყობილობა ჯერ კიდევ არსებობს, რასაც ცოცხალი ბმულის მქონე დამხმარეები მოითხოვენ.

არცერთი მითითება არ აიძულებს კაუჭს SIGKILL-ის შემდეგ იმუშაოს. უფლებებიც არ აღდგება down-pre-ით: თუ დემონი დაეშვება user ან group დონეზე ან შევა chroot გარემოში, კაუჭი იმ წვდომით მუშაობს, რასაც ეს ტოვებს. გამოძახებულმა კაუჭმა მაინც შეიძლება ვერ შეძლოს რეზოლვერის განახლება. OpenVPN-ის ცნობარი მოიცავს სიგნალებს და callback-ის სასიცოცხლო ციკლს.

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

შეამოწმეთ მდგომარეობა, რომელიც ნამდვილად რჩება

სისტემაში, რომელიც systemd-resolved-ს იყენებს, resolvectl status გვიჩვენებს, რომელი ბმული კვლავ ატარებს VPN-ის DNS სერვერებს ან მარშრუტიზაციის დომენებს. ეს ბმული შეიძლება ეკუთვნოდეს წასულ კავშირს ან სხვა, ჯერ კიდევ აწეულ ტუნელს.

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

აღადგინეთ სხვა ბმულის მოპარვის გარეშე

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

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