რომელი ბმული პასუხობს: მარშრუტიზაციის დომენები split-tunnel VPN-ის DNS-ისთვის

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

პირველი ნაბიჯი: გამოყავით მარშრუტი გამხსნელისგან

ipv4.never-default პასუხობს მარშრუტიზაციის კითხვას და უშლის NetworkManager-ს ამ კავშირის დაყენებას მთელი IPv4 ტრაფიკის გზად. DNS მარშრუტიზაციის დომენი პასუხობს სხვა კითხვას: რომელი ბმულის სახელების სერვერები იღებენ შესაბამისი სუფიქსის მოთხოვნას. არც ერთი არ გულისხმობს მეორეს და პროფილს შეიძლება წლების განმავლობაში ჰქონდეს ერთი, მეორის არქონისას. მხოლოდ მარშრუტი ნიშნავს, რომ გვირაბი ატარებს კომპანიის ქვექსელებს და მისი გამხსნელი პასუხობს კომპანიის სახელებს, დანარჩენი კი უცვლელი რჩება.

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

მეორე ნაბიჯი: დაამატეთ მხოლოდ-მარშრუტიზაციის დომენი პროფილს

დავუშვათ, კავშირს ჰქვია corp-vpn, კომპანიის სუფიქსია internal.example და გვირაბის გამხსნელი უკვე ხელმისაწვდომია. ჯერ წაიკითხეთ მიმდინარე მნიშვნელობები, რადგან ქვემოთ მოცემული ბრძანებები ცვლის თვისებებს, რომლებსაც შეიძლება უკვე ჰქონდეთ ჩანაწერები.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

საწყისი ტილდა აღნიშნავს მხოლოდ-მარშრუტიზაციის დომენს, ამიტომ შესაბამისი მოთხოვნები ამ ბმულის სერვერებზე მიდის და სუფიქსი მოკლე სახელებს არ ემატება. მოხსენით ტილდა და იგივე სტრიქონი საძიებო სუფიქსიც გახდება, რაც განსხვავებული შედეგია და ადამიანები იშვიათად იმას გულისხმობენ. ზემოთ ორივე პარამეტრი IPv4-ია, ამიტომ ორმაგი სტეკის პროფილს სჭირდება ipv6.never-default და იგივე მარშრუტიზაციის დომენი ipv6.dns-search-ში, თორემ IPv6 მხარე კვლავ ნაგულისხმევ მარშრუტს იყენებს და იქ შიდა სახელები ვერ იხსნება.

მესამე ნაბიჯი: ჰკითხეთ resolvectl-ს, რომელი ბმული პასუხობდა

გაუშვით resolvectl status და წაიკითხეთ თითოეული ბმულის DNS სერვერები და დომენები, შემდეგ გაუშვით resolvectl query host.internal.example რეალური შიდა სახელის წინააღმდეგ, რომლის მოთხოვნაც ნებადართული გაქვთ. მეორე ბრძანება ერთადერთი პირდაპირი მტკიცებულებაა, რომ მარშრუტიზაციის დომენი თავის საქმეს ასრულებს, რადგან ის ასახელებს ბმულს, რომელმაც უპასუხა. მხოლოდ სტატუსის სია ამტკიცებს კონფიგურაციას; მოთხოვნა ამტკიცებს ამოხსნას.

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

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

მეოთხე ნაბიჯი: როცა სახელი იხსნება, სერვისი კი არა

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

Samba-ს ცვლილება, რომელიც ამ კითხვის გვერდით ტრიალებს, ეხება წვდომის ფენას და არა DNS-ის არჩევანს. მისი გამოყენება სახელების ამოხსნის ხარვეზზე სწორედ ის გზაა, რომლითაც პატარა პრობლემა მეორეს იძენს.

მეხუთე ნაბიჯი: არ შეცვალოთ გამხსნელი დაკარგული დომენის გამოსასწორებლად

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

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