როგორ წავიკითხოთ VPN DNS-ის მარშრუტიზაცია თითოეული ბმულისთვის resolvectl-იდან
resolvectl status აჩვენებს სერვერებს, დომენებს და ნაგულისხმევ მარშრუტს თითოეული ბმულისთვის. წაიკითხეთ ისინი ერთად, შემდეგ ჰკითხეთ სახელს და აღნიშნეთ, რომელმა ბმულმა უპასუხა.
გაუშვით resolvectl status და მიიღებთ კედელს ბლოკებისა თითოეული ბმულისთვის, თითოეული საკუთარი სერვერებითა და საკუთარი დომენების ხაზით. მარშრუტიზაციას განსაზღვრავს დომენების სია და არა სახელის სერვერის მისამართი, რადგან ლოკალური stub ყოველ მოთხოვნას უგზავნის იმ ბმულს, რომელიც სახელს ითხოვს. წაიკითხეთ ეს მოთხოვნები პასუხის წაკითხვამდე, შემდეგ ჰკითხეთ სახელს და შეამოწმეთ, რომელმა ბმულმა შექმნა ის. სწორი ბმულიდან არასწორი პასუხი სხვა პრობლემაა, ვიდრე არასწორი ბმულიდან სწორი პასუხი.
რას გეუბნებათ თითოეული ბმულის ბლოკი
თითოეული ბლოკი ჩამოთვლის სერვერებს, რომლებსაც გადამწყვეტი გამოიყენებს ამ ინტერფეისისთვის, დომენების სიას და იმას, არის თუ არა ბმული ნაგულისხმევი მარშრუტი. დომენების სია მოთხოვნების სიმრავლეა და გადამწყვეტი იყენებს ყველაზე გრძელი სუფიქსის დამთხვევას: host.corp.example-ის მოთხოვნას ითხოვს corp.example-ის მატარებელი ბმული, სანამ მხოლოდ ნაგულისხმევი მარშრუტის მატარებელი. ორი ბმული, რომლებიც ერთსა და იმავე სუფიქსს ითხოვენ, შედეგს ტოვებენ პრიორიტეტსა და რიგზე, ამიტომ დუბლიკატები პირველ რიგში ყურადღებას იმსახურებენ. მიმდინარე სერვერის ხაზი აჩვენებს, ჩამოთვლილი სერვერებიდან რომელი გამოიყენება იმ მომენტში.
Stub-მისამართი, მაგალითად 127.0.0.53 /etc/resolv.conf-ში, მხოლოდ ამბობს, რომ stub წინ არის. ის არ ასახელებს პასუხის გამცემ ზედა დინებას, ამიტომ მხოლოდ resolv.conf-ზე დაფუძნებული დიაგნოსტიკა იჭედება.
სწორად წაიკითხეთ დომენის ჩანაწერის სამი ტიპი
| ჩანაწერი | რას ითხოვს | ჩვეულებრივი შეცდომა |
|---|---|---|
| corp.example | მარშრუტიზაციის დომენი და ძიების სუფიქსი: მის ქვეშ არსებული სახელები ამ ბმულზე მიდის და სტრიქონი ემატება შიშველ სახელებს | ამოღებულია, რადგან მარშრუტიზაცია მაინც მუშაობს თითქოს |
| ~corp.example | მხოლოდ მარშრუტი: მის ქვეშ არსებული სახელები ამ ბმულზე მიდის, მაგრამ სუფიქსი არ ემატება | ვივარაუდეთ, რომ მარშრუტიზაციისთვის აუცილებელია |
| ~. | ნაგულისხმევი მარშრუტი: ითხოვს მოთხოვნებს, რომლებსაც არც ერთი სხვა ბმული არ ფარავს | გააქტიურებული დარჩა გაყოფილ პროფილზე, ამიტომ საჯარო სახელები გვირაბს მიჰყვება |
ტილდა ცვლის ძიების ქცევას და არა მარშრუტიზაციას. ჩანაწერი ტილდის გარეშე არის როგორც მარშრუტიზაციის დომენი, ისე ძიების დომენი, ამიტომ მის ქვეშ არსებული სახელები იგზავნება ამ ბმულზე და ერთეტიკიან სახელებს ემატება სუფიქსი. ტილდიანი ჩანაწერი მარშრუტიზაციას უკეთებს იმავე სუფიქსს, მაგრამ ტოვებს მას ძიების სიის გარეთ. ამიტომ ტილდის მოშორება ცვლის, რომელი შიშველი სახელები წყდება, და ამიტომ ტილდის არარსებობა ძიების პრობლემაა და არა გაყოფილი DNS-ის მარცხი.
ნაგულისხმევი მარშრუტის ჩანაწერი ითხოვს ყველაფერს, რასაც არც ერთი სხვა ბმული არ ფარავს. სრული გვირაბის პროფილი ჩვეულებრივ ისურვებს მას, ხოლო გაყოფილი პროფილი ჩვეულებრივ არა, რადგან საჯარო სახელები მაშინ კერძო გადამწყვეტთან მიდის და შეიძლება იქ ჩავარდეს. წაიკითხეთ ცხრილი პროფილის განზრახვის მიმართ და არა დროშების კოპირება პროფილებს შორის. როცა ორი ბმული ერთსა და იმავე სუფიქსს ითხოვს, გადაწყვიტეთ პრიორიტეტის საკითხი, სანამ სხვა რამეს შეცვლით.
ჰკითხეთ სახელი და ნახეთ, რომელმა ბმულმა უპასუხა
query ქვებრძანება ბეჭდავს მისამართს, პროტოკოლს და იმ ბმულს ან არეს, რომელმაც პასუხი შექმნა. გამოსცადეთ ერთი სახელი, რომელიც კერძო სუფიქსმა უნდა მოითხოვოს, და ერთი ჩვეულებრივი საჯარო სახელი, შემდეგ შეადარეთ მოხსენებული წყაროები. თუ კერძო სახელი უსადენო ბმულიდან პასუხობს, მოთხოვნა აკლია ან გვირაბი გათიშულია; თუ საჯარო სახელი გაყოფილ პროფილზე გვირაბიდან პასუხობს, ნაგულისხმევი მარშრუტი ძალიან ფართოა. ეს ორი მარცხი ბრაუზერში ერთნაირად ჩანს, ამ გამოსავალში კი საპირისპიროდ.
resolvectl status
resolvectl query host.corp.exampleთვალი ადევნეთ მოხსენებულ პროტოკოლსაც, რადგან ქეშიდან ან hosts ფაილიდან პასუხი შეიძლება მოვიდეს ზედა დინების არც ერთი შეკითხვის გარეშე. ქეშიდან მიღებული პასუხი ადასტურებს, რომ სახელი ოდესღაც გადაწყდა და არა იმას, რომ მიმდინარე პოლიტიკა მას სწორად მარშრუტიზაციას უკეთებს.
გამოყავით სახელების მარშრუტიზაცია პაკეტების მარშრუტიზაციისგან
გადამწყვეტის გადაწყვეტილება გზას არ ქმნის. არჩეულ სერვერს მაინც სჭირდება მარშრუტი საკუთარ მისამართამდე, ხოლო დაბრუნებულ მისამართს მაინც სჭირდება მარშრუტი კერძო ქსელში, ამიტომ სწორ DNS პოლიტიკა შეიძლება თანაარსებობდეს იმ კავშირთან, რომელიც არასდროს იხსნება. როცა სახელი წყდება და აპლიკაცია მარცხდება, შეამოწმეთ მისამართი და მარშრუტი და არა კვლავ DNS-ის შეცვლა. სახელის გადაწყვეტა და ხელმისაწვდომობა ორი კითხვაა ორი სხვადასხვა მფლობელით.
აპლიკაციებს შეუძლიათ მთლიანად გვერდი აუარონ სისტემურ გადამწყვეტს საკუთარი უსაფრთხო DNS პარამეტრით ან ჩაშენებული გადამწყვეტით. resolvectl-ის შედეგი აღწერს სისტემურ გზას, და ბრაუზერი, რომელიც მას უგულებელყოფს, თქვენი ყველა ტესტის საწინააღმდეგოს გვიჩვენებს. შეამოწმეთ ეს პარამეტრი, სანამ დაასკვნით, რომ პოლიტიკა გატეხილია.
ჩაწერეთ მისამართი, რომელზეც სახელი გადაწყდა, ბმულის გვერდით. სწორი სახელი, რომელიც არასწორ მისამართზე მიუთითებს, ჩანაწერის პრობლემაა და არა მარშრუტიზაციის.
ხელახლა შეამოწმეთ ბმულის შეცვლის შემდეგ
ხელახალი დაკავშირება ან უსადენო ქსელის შეცვლა ხელახლა აშენებს ბმულის მდგომარეობას და ქსელის მენეჯერმა შეიძლება ხელახლა დააყენოს თავისი დომენები და სერვერები ხელით დაყენებულ ყველაფერზე. ამის შემდეგ ჰკითხეთ იგივე ორ სახელს და შეადარეთ ჩაწერილ საწყის ხაზს. თუ ხელით შეტანილი ცვლილება გაქრა, გასწორება კავშირის პროფილში უნდა იყოს და არა shell ბრძანებაში. სწორედ წინ და შემდეგ ჩაწერა ხდის ამას თვალსაჩინოს.
გააზიარეთ მხოლოდ ის სახელები და სერვერის კონტექსტი, რაც ანგარიშს სჭირდება, რადგან შიდა სუფიქსები ტოპოლოგიას ამხელს. systemd-resolved-ის დოკუმენტაცია დომენების მარშრუტიზაციაზე მოიცავს ყველაზე გრძელი დამთხვევის წესსა და ტილდის ქცევას, და ერთხელ წაკითხვა ხელს უშლის ზემოთ მოცემული ცხრილის შეცდომების უმეტესობას: systemd-resolved-ში მოთხოვნების მარშრუტიზაცია.