მოკლული openconnect: მარშრუტები და DNS კვლავ გვირაბისკენ მიუთითებს

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

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

დაიწყეთ პროცესით, და არა კონფიგურაციით

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

თუ არაფერი მუშაობს, შეხედეთ ბმულს. ip link show tun0 გეუბნებათ, გადარჩა თუ არა ინტერფეისი, და ip route show dev tun0 ჩამოთვლის მარშრუტებს, რომლებიც ჯერ კიდევ მასზეა მიბმული. შემდეგ შეამოწმეთ resolver ამით resolvectl status. ჩაწერეთ სამივე გამომავალი, სანამ შეცვლით, რადგან სწორედ ეს ჩანაწერია ის გზა, რომლითაც მოგვიანებით განასხვავებთ ძველ ჩანაწერს ახლისგან.

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

სწორედ დამხმარე სკრიპტი აბრუნებს ცვლილებებს

openconnect თავად არ შლის ინტერფეისს, მარშრუტებს ან resolver-ის ჩანაწერებს. ის იძახებს გარე დამხმარეს, /etc/vpnc/vpnc-script upstream build-ში და /usr/share/vpnc-scripts/vpnc-script Debian და Ubuntu პაკეტებში, არჩევანი ასეთია: -s. იგივე სკრიპტი, რომელიც გვირაბს ზემოთ აყენებს, არის ის, რომელიც მას ხსნის.

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

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

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

გაგზავნეთ სიგნალი, რომელსაც თქვენი build ადოკუმენტირებს

როცა სიგნალი იცით, გააჩერეთ პროცესი pid-ით და არა შაბლონით.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

შემდეგ გაიმეორეთ პირველი ნაწილის სამი შემოწმება, გასვლის სტატუსის ნდობის ნაცვლად. ip link show tun0 უნდა ჩავარდეს, ip route show dev tun0 არაფერი არ უნდა დაბეჭდოს, და resolvectl status აღარ უნდა ჩამოთვალოს VPN ბმული.

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

შეაკეთეთ resolver resolv.conf-ის ჩანაცვლების გარეშე

Ubuntu-ს უმეტეს სისტემებში /etc/resolv.conf systemd-resolved-ის სიმბოლური ბმულია, და არა ფაილი, რომელიც უნდა შეასწოროთ. მისი ჩანაცვლება არღვევს სახელების გარჩევას ყველა ქსელისთვის, და არა მხოლოდ VPN-ისთვის. სამაგიეროდ, მოხსენით გვირაბის რეგისტრაცია:

resolvectl revert tun0
resolvectl query example.com

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

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

შემდეგი გათიშვა მოსაბეზრებელი გახადეთ

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

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