resolv.conf-ის რედაქტირება VPN-ის გათიშვის შემდეგ DNS-ს არ ასწორებს

თიშავთ VPN-ს, ping 1.1.1.1 კვლავ პასუხობს და ყოველი სახელის მოთხოვნა იკიდება, სანამ გვერდი საბოლოოდ დანებდება. შემდეგ cat /etc/resolv.conf აჩვენებს სახელების სერვერს, რომელიც ოდესმე მხოლოდ გვირაბის შიგნით არსებობდა, ჩვეულებრივ სიის პირველი. ამ ხაზის წაშლა თითქოს ასწორებს საკითხს დაახლოებით ათი წუთით, სანამ ჩაძინება, Wi-Fi-ის როუმინგი ან გადატვირთვა დააბრუნებს. ფაილი, რომელიც შეასწორეთ, პარამეტრი არ არის; ის ბმულის მდგომარეობის გამოსახულებაა, რომელიც სხვა კომპონენტს ეკუთვნის.

რატომ ღირს ერთი მოძველებული ჩანაწერი წამები თითო მოთხოვნაზე

glibc-ის გადამწყვეტი რიგრიგობით გადის სახელების სერვერების სიას და ელოდება დროის ამოწურვას, სანამ შემდეგს სცდის, ხოლო resolv.conf(5) ამ სიას სამ ჩანაწერამდე ზღუდავს. გვირაბის მხრიდან გადამწყვეტი, მაგალითად 10.8.0.1, სიის თავში ჩასვით მას შემდეგ, რაც გვირაბი გაქრა, და ყოველი მოთხოვნა გადაიხდის დროის ამოწურვას, სანამ პასუხისმგებელ სერვერზე გადავა. ამიტომ სიმპტომი მკვდარ კავშირს ჰგავს და არა DNS შეცდომას: ბრაუზერები იბლოკება, დრო ეწურებათ და ზოგჯერ ქეშირებულ მისამართს აწვდიან, რომელიც მოგვიანებით მოძველდება.

ეს ასევე ხსნის, რატომ მოდის საჩივარი როგორც „ინტერნეტი გატყდა“. IP მისამართზე ping ამტკიცებს, რომ ბმული რიგზეა, რაც ხარვეზს აპლიკაციისას ხდის. გადამწყვეტების სია პირველია, რაც უნდა წაიკითხო, და უკანასკნელი, რაც უნდა შეასწორო.

მითი: resolv.conf პარამეტრების ფაილია

სანამ შეცვლით, ჰკითხეთ, რა არის სინამდვილეში ეს გზა:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

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

resolvectl status არის ხედი, რომელიც სიმართლეს ამბობს: DNS სერვერები თითო ბმულზე, მარშრუტიზაციის დომენები და არსებობს თუ არა ჯერ კიდევ გვირაბის ბმული. resolvectl query example.com უფრო შორს მიდის და აჩვენებს, რომელი ინტერფეისი უპასუხა. გამოიყენეთ ორივე, სანამ ფაილს შეეხებით, და გახსოვდეთ, რომ საკუთარი უსაფრთხო DNS-ის მქონე ბრაუზერი ყოველივე ამას უგულებელყოფს.

იპოვეთ მფლობელი, სანამ რამეს შეასწორებთ

ჩვეულებრივ სამი კომპონენტი ეჯიბრება ერთსა და იმავე პარამეტრს: systemd-resolved, NetworkManager და ის, რაც VPN კლიენტმა დააყენა. ჯერ ცოცხალი გამოავლინეთ:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

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

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

მოკლულ კლიენტს არ შეუძლია საკუთარი გასუფთავების კაუჭის გაშვება. SIGKILL საერთოდ არ იჭერს, SIGINT და SIGTERM კი იჭერა, ამიტომ ძალით მოკვლის შემდეგ „უბრალოდ გაჩერებული“ გვირაბი ხშირად ადგილზე ტოვებს ინტერფეისის რეგისტრაციასაც და გადამწყვეტის ჩანაწერსაც. იპოვეთ კონკრეტული PID და სიგნალი მხოლოდ მას გაუგზავნეთ:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

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

resolvectl revert აღადგენს ამ ბმულის გაშვების დროის DNS კონფიგურაციას, რაც უფრო ვიწროა, ვიდრე გადამწყვეტის გადატვირთვა და გაცილებით ვიწრო, ვიდრე გლობალური ფაილის რედაქტირება. თუ გვირაბის ბმული სრულიად გაქრა, systemctl restart NetworkManager ხელახლა აშენებს კავშირის მდგომარეობას და ეს არის ის ნაბიჯი, რომელსაც წყაროს ნაკადები გამუდმებით უბრუნდებიან. მიაქციეთ ყურადღება Restart=always მქონე სერვისების მენეჯერს, რადგან მან შეიძლება მოკლული კლიენტი და მისი DNS პარამეტრები პირდაპირ დააბრუნოს.

მეორე მიმართულება: გაგზავნილი DNS, რომელიც არასოდეს ჩამოვიდა

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

შეამოწმეთ გადაცემა ხელით შესრულებით, რაც ჰყოფს „სერვერი არასწორია“-ს „არავის გამოიყენა“-სგან:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

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

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

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

ხრიკები, რომლებიც შემდეგ ავარიად იქცევიან

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

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

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