შეაჩერეთ ორი Linux სერვისის კონკურენცია /etc/resolv.conf-ის გამო

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

შემოწმება 1: სიმბოლური ბმულია თუ არა, და საით

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

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

ბმული systemd-resolved-ის stub ბილიკზე ნიშნავს, რომ ფაილის შიგთავსი გენერირდება, და ხელით რედაქტირება გადაიწერება შემდეგ მოვლენაზე. ჩვეულებრივ ფაილს nameserver-ის სტრიქონებით, როგორც წესი, წერს ის კლიენტი ან DHCP-ის კაუჭი, რომელიც დაკავშირებისას მუშაობს. ორივე ლეგიტიმურია; მთავარია იცოდეთ, რომელი გაქვთ, სანამ რამეს შეცვლით.

შემოწმება 2: რომელი დემონი მუშაობს

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

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

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

NetworkManager-ის საკუთარი კონფიგურაცია წყვეტს, რომელ ამ backend-ს იყენებს. მისი dns= პარამეტრი მთავარ კონფიგურაციის ფაილში ირჩევს მის შიდა გადამწყვეტს, dnsmasq-ს, systemd-resolved-სა და none-ს შორის, და შეიძლება დისტრიბუტივმა თქვენ ნაცვლად აირჩია. წაიკითხეთ ეს პარამეტრი, სანამ გადაწყვეტთ, რას ნიშნავს „DNS-ის გასწორება“ ამ ჰოსტზე.

შემოწმება 3: რისი დაწერა აქვს უფლება VPN კლიენტს

აქ ჩვეულებრივ ცხოვრობს კონფლიქტი. VPN კლიენტი, რომელიც გადამწყვეტის ფაილს პირდაპირ გადაწერს, ებრძოლება ყველა იმ სერვისს, რომელიც მასაც ემსახურება, და აგებს ის, ვინც პირველი მუშაობს. OpenVPN-ის ბოლო გამოშვებებს შეუძლიათ DNS პარამეტრები systemd-resolved-ს გადასცენ ფაილის გადაწერის ნაცვლად, რაც სწორედ ის თანამშრომლობითი ქცევაა, რომელიც გსურთ; ძველი სკრიპტები და ხელით დაწერილი კაუჭები ხშირად მოძველებულ დამხმარეს იძახებენ ან უბრალოდ გადაწერენ ფაილს.

WireGuard-ის სიტუაცია ფორმით მსგავსია: თავად ინტერფეისის კონფიგურაცია DNS-ს არ მართავს, ამას აკეთებენ მის გარშემო არსებული ხელსაწყოები, გადამწყვეტის დამხმარის ან resolved-ის ინტეგრაციის მეშვეობით. თუ ორი ასეთი დამხმარეა დაყენებული, ორივე შეეცდება დაკავშირებისას თავისი მსოფლხედვა დააწესოს.

წაიკითხეთ კლიენტის up და down კაუჭები, ნაცვლად გამოცნობისა. რამდენიმე სტრიქონი shell /etc/openvpn/up.sh-ში ან ეკვივალენტურ დირექტორიაში ხსნის ქცევას, რომელიც სხვაგვარად შემთხვევითი ჩანს, და სწორედ იქ შეგიძლიათ აიძულოთ კლიენტი ითანამშრომლოს და არა დაუპირისპირდეს.

შემოწმება 4: გაასწორეთ ის მფლობელთან, და არა ფაილში

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

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

სადაც ორი კომპონენტი ნამდვილად უნდა თანაარსებობდეს, მიეცით მათ სხვადასხვა საქმე. დაე, ქსელის მმართველი ფლობდეს ინტერფეისის დონის კონფიგურაციას, დაე, VPN კლიენტმა იმავე ინტეგრაციის მეშვეობით შეიტანოს წვლილი თითო ბმულის DNS-სა და დომენებში, და წაშალეთ მესამე სკრიპტი, რომელიც ფაილს პირდაპირ წერს. systemd-resolved-ის დოკუმენტაცია აღწერს მის მხარდაჭერილ რეჟიმებს და რას აჩვენებს თითოეული /etc/resolv.conf-ში. აირჩიეთ რეჟიმი, რომელიც შეესაბამება შესანარჩუნებელი პოლიტიკის მოცულობას. თუ split DNS მნიშვნელოვანია, stub მოწყობა თითო ბმულის დომენებით ინახავს მას, ხოლო რეჟიმი, რომელიც upstream სერვერებს ფაილში აკოპირებს, ჩუმად აბრტყელებს მას.

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

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

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

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