VPN-ის DNS ყველა მოთხოვნას იკავებს: გაასწორეთ dns-priority NetworkManager-ში

დაუკავშირდით ოფისის VPN-ს და უცებ ყველა სახელის მოთხოვნა კორპორატიულ resolver-ზე მიდის. საჯარო სახელები კვლავ წყდება, ამიტომ არაფერი გატეხილად არ ჩანს, სანამ ლოკალური პრინტერის სახელი არ ჩავარდება ან split-horizon ჩანაწერი ოფისის მისამართს არ დააბრუნებს. ზოგიერთ Fedora-ს დაყენებაზე პირიქით ხდება: პროვაიდერის resolver პასუხს განაგრძობს გვირაბის აწევის შემდეგაც. ორივე ერთი კითხვაა — რომელი resolver არის ამ მოთხოვნის მფლობელი — და NetworkManager სისტემებში პასუხი ცხოვრობს თითოეული კავშირის DNS თვისებებში.

ორი კავშირი, ერთი გამარჯვებული resolver

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

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

პრიორიტეტი წყვეტს რიგს, საძიებო სია — საკუთრებას

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

საძიებო სია საკუთრების განაცხადია. შიშველი დომენი, როგორიცაა corp.example, ხდება საძიებო სუფიქსი და მარშრუტიზაციის დომენი. მხოლოდ მარშრუტიზაციის ფორმა ~corp.example ამ სუფიქსის ქვეშ მყოფ მოთხოვნებს ამ კავშირზე აგზავნის დომენის მოკლე სახელებზე დამატების გარეშე. ეს ტილდა განსხვავებაა «ჰკითხე ამ სერვერს» და «ჰკითხე ამ სერვერს და დაამთავრე ჩემი აკრეფა» შორის.

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

შემდეგ გახადეთ უპირატესობა ცხადი და ხელახლა გაააქტიურეთ:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

უარყოფითი პრიორიტეტი დოკუმენტირებული გზაა იმის სათქმელად «უპირატესობა მიეცი ამ კავშირს», და ორივე მისამართის ოჯახის დაყენება ქცევას თანმიმდევრულს ინარჩუნებს IPv6 კავშირის მქონე ჰოსტზე. თვისების შეცვლა კავშირის ხელახალი გააქტიურების გარეშე არაფერს ცვლის იმაში, რაც ახლა მუშაობს, ამიტომ მიმდევრობა მთავრდება ცხადი up-ით.

მიეცით systemd-resolved-ს გაყოფის შენარჩუნება

ნაგულისხმევი dnsmasq დანამატი მოთხოვნებს ერთ ლოკალურ resolver-ში ასხამს, ამიტომ ბმულის მიხედვით გამოყოფა უხეში რჩება. systemd-resolved გაყოფას ბმულის მიხედვით აჩვენებს, და resolvectl query ასახელებს ბმულს, რომელმაც უპასუხა.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

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

შეუსაბამეთ DNS დიზაინი გვირაბის ტიპს

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

შემდეგ არის kill switch, რომელიც გვირაბის გარეთ DNS-ს ბლოკავს. სახელები წყდება გვირაბის ზონებისთვის და ყველგან სხვაგან ვარდება, სანამ კავშირი სრულიად ჯანსაღია. სამუშაო პასუხებია ცხადი ნებართვა LAN-ის resolver-სთვის ან ლოკალური ქეში, რომელიც მხოლოდ კორპორატიულ ზონას გადასცემს, და ორივე მფლობელის მქონე გამონაკლისია და არა გვირაბის ხარვეზი.

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

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

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

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