გაყოფილი გვირაბი ბრაუზერს გამორიცხავს, და არა მის DNS მოთხოვნებს
პირდაპირი მონაცემთა გზა სახელების გარჩევას არ გადაადგილებს. შეამოწმეთ, რომელი რეზოლვერი იღებს მოთხოვნას და იყო თუ არა ეს განზრახვა, სანამ გაჟონვას უწოდებთ.
ბრაუზერი გვირაბიდან გამორიცხულია, საჯარო IP-ის გვერდი ადასტურებს, რომ მისი ტრაფიკი სახლის კავშირით გადის, და შიდა ვიკი მაინც არ იხსნება. სახელების გარჩევა სხვაგან წავიდა, და ეს სხვაგან ჩვეულებრივ ის რეზოლვერია, რომელიც VPN-მა დააყენა. მონაცემთა გზა და რეზოლვერის გზა ცალკე გადაწყვეტილებებია გაყოფილი გვირაბის უმეტეს დიზაინში. შეამოწმეთ, რომელი გამოიყენა ბრაუზერმა სინამდვილეში, სანამ გამორიცხვას გატეხილს უწოდებთ.
მონაცემთა გზა და რეზოლვერის გზა იყოფა
გამორიცხვა აპლიკაციის პაკეტებს გვირაბიდან ამოიღებს, რაც მარშრუტიზაციისა და ფაიერვოლის გადაწყვეტილებაა მონაცემთა გზაზე. სახელების გარჩევა სხვა ძიებაა: პროცესი სისტემის რეზოლვერს ეკითხება, და ის რეზოლვერი წყვეტს, რომელი სერვერი მიიღებს კითხვას.
ორივე შეიძლება იყოს განზრახ და განსხვავებული. სამუშაო განლაგებამ შეიძლება შიდა სახელთა სივრცეები კორპორატიულ რეზოლვერთან დატოვოს, ხოლო შერჩეული საჯარო დათვალიერება გვირაბის გარეთ გაგზავნოს, სწორედ იმიტომ, რომ შიდა სახელები სხვაგან არ გარჩევდება. დამაბნეველი შემთხვევა საპირისპიროა: საჯარო საიტი ვერ იხსნება, რადგან ბრაუზერმა არასოდეს ჰკითხა იმ რეზოლვერს, რომელსაც განლაგება მოელოდა. ჩაწერეთ მარშრუტი და რეზოლვერი ცალ-ცალკე, და კამათის ნახევარი გაქრება.
იპოვეთ, რომელი პროცესი სვამს კითხვას
ბრაუზერს შეუძლია გამოიყენოს სისტემის რეზოლვერი, საკუთარი დაშიფრული DNS სერვისი, ან რეზოლვერი, რომელსაც ოპერაციული სისტემა თითოეული ქსელისთვის ანიჭებს. პირველი პლატფორმის პოლიტიკას მიჰყვება, მეორე მთლიანად გვერდს უვლის ამ პოლიტიკას, ხოლო მესამე დამოკიდებულია იმაზე, რომელ რგოლზე მიემართება მოთხოვნა.
resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40
წაიკითხეთ მოქმედი კონფიგურაცია ტესტამდე: რომელი რგოლები ატარებენ DNS სერვერებს, რომელ სახელთა სივრცეებს აცხადებენ, და ხომ არ ცვლის სახელის მიხედვით პოლიტიკა ნაგულისხმევს. Linux-ზე გაყოფილი DNS მარშრუტიზაციის დომენებს იყენებს; Windows-ზე სახელების გარჩევის პოლიტიკის ცხრილი იგივეს აკეთებს სახელთა სივრცეებისთვის. არც ერთი არ ჩანს გაჟონვის ტესტის გვერდიდან.
გადაწყვიტეთ, რომელი რეზოლვერი რომელ სახელს ხედავს
ჩაწერეთ განზრახული დაკავშირება, სანამ რამეს შეცვლით: შიდა სახელები კორპორატიულ რეზოლვერთან, საჯარო სახელები იმ სერვისთან, რომელსაც პოლიტიკა უშვებს, და გამონაკლისები პასუხისმგებელთან ერთად. ამ სიის გარეშე გაჟონვის ტესტის ყოველი იარლიყი პოლიტიკურ კამათად იქცევა, რომელსაც ვერავინ გადაწყვეტს.
შემდეგ შეამოწმეთ თავად ბრაუზერის პარამეტრი, რადგან ბრაუზერში დაშიფრული DNS გამოიყენება მანამ, სანამ ოპერაციული სისტემა მოთხოვნას მიიღებს. მომხმარებელმა, რომელმაც ის ჩართო დატყვევების პორტალის გვერდის ასავლელად, ჩუმად გადაფარა რეზოლვერი, რომელიც განლაგებამ აირჩია. ეს კონფიგურაციის გადაწყვეტილებაა და არა გაჟონვა, და ის იმსახურებს გადაწყვეტილებას და არა ბლოკსიას.
ნუ გადაწერთ ყოველ DNS ველს, რომ ერთი ტესტის იარლიყი მწვანე გახდეს. იარლიყი აღწერს ერთი პროცესის ერთ მოთხოვნას ერთ მომენტში.
შეამოწმეთ მოთხოვნა და კავშირი ცალ-ცალკე
გამოსცადეთ ორივე გზა დამოუკიდებლად. კავშირის ტესტი აჩვენებს მონაცემთა მარშრუტს, ხოლო რეზოლვერის ტესტი აჩვენებს, ვინ მიიღო სახელი.
curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net
ჰკითხეთ რეზოლვერსაც ცალსახად, რომ წარუმატებლობა სერვერს დაეკისროს და არა გზას. შემდეგ გადატვირთეთ ბრაუზერი და გაიმეორეთ, რადგან აპლიკაციები უარყოფით პასუხებს ქეშავენ და ძველი წარუმატებლობა მუდმივად გვეჩვენება.
დამტკიცებული ცვლილების შემდეგ ჩაწერეთ მონაცემთა მარშრუტი და რეზოლვერის მიმღები როგორც ორი ცალკე ხაზი თარიღთან ერთად. თუ ქცევა შემდეგ ხელახლა დაკავშირებისას დაბრუნდება, უნდა გასწორდეს ის პროფილი, რომელიც მას აძლევს, და არა ბრაუზერი.