Pritunl-ის კერძო DNS არ მუშაობს? დაამატეთ ვიწრო resolver-მარშრუტი

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

დაადასტურეთ, რომ რეზოლვერი თქვენს კლიენტთა პულს უარყოფს

დაიწყეთ იმის დამტკიცებით, რომ ხარვეზი წყაროს ეხება და არა ხელმისაწვდომობას. დაკავშირებული კლიენტიდან პირდაპირ ჰკითხეთ კერძო რეზოლვერს და დააკვირდით, ვადა იწურება თუ უარყოფად ბრუნდება. dig @10.40.0.53 intranet.example.net +time=2 +tries=1-ის ვადის ამოწურვა, მაშინ როცა იგივე მოთხოვნა კარიბჭიდან წარმატებულია, რეზოლვერზე წვდომის პოლიტიკაზე მიუთითებს. SERVFAIL პასუხი სრულიად სხვა ადგილს, ჩვეულებრივ ზონას ან ზედა დინების გადამცემს მიუთითებს.

ტესტირებამდე ჩაწერეთ კლიენტის მისამართი. კლიენტზე ip -4 addr show tun0, ან კონსოლში ნაჩვენები იჯარა გეტყვით, რომელ პულს ხედავს რეზოლვერი.

შემდეგ დაადასტურეთ, რომ გზა საერთოდ არსებობს. მარშრუტი, რომელიც რეზოლვერის მისამართს გვირაბში აგზავნის, წინაპირობაა და არა გადაწყვეტა; თუ პაკეტები არასოდეს აღწევს, წყაროს პოლიტიკა საერთოდ არ განიხილება. შეამოწმეთ კლიენტზე ip route get 10.40.0.53-ით.

დაამატეთ ერთი ჰოსტმარშრუტი ყველაფრის თარგმნის ნაცვლად

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

დააკონფიგურირეთ ის სერვერის მხარდაჭერილი მარშრუტის მფლობელის მეშვეობით, არსებული მარშრუტების გადაფარვაზე გადამოწმების შემდეგ. ზემოთ მოცემულ მაგალითში დანიშნულებაა NAT-ით 10.40.0.53/32, და კლიენტთა პული რჩება 10.90.0.0/24. ნუ თარგმნით მთელ კერძო დიაპაზონს ერთი სერვისის გამოსასწორებლად, რადგან კლიენტის რეალურ მისამართზე დამოკიდებული ყოველი ქვედა დინების პოლიტიკა დაიწყებს კარიბჭის ხედვას მის ნაცვლად. დაადასტურეთ მისამართი, რომელსაც რეზოლვერი რეალურად იღებს, ტესტური ძიების დროს მისი მოთხოვნების ჟურნალის დაკვირვებით. მხოლოდ ჰოსტმარშრუტი არაფერს ამტკიცებს თარგმნისა თუ ნებართვის შესახებ.

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

გადაწყვიტეთ, სერვერი აგზავნის მოთხოვნას თუ კლიენტი

Pritunl ასევე აღწერს DNS-პროქსის მოწყობას, რომელიც დაკავშირებულია VPN Client DNS Mapping-თან, სადაც სერვერი კლიენტების ნაცვლად ზედა დინების მოთხოვნებს გადასცემს. ამ მოდელში ზედა დინების წყარო სერვერის საკუთარ ქსელურ კონტექსტს ეკუთვნის, და კლიენტის მხარეს გამონაკლისი არასწორი გამოსწორებაა.

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

გამოსცადეთ კერძო ძიება და არა საჯარო ვებგვერდი

ცვლილების გამოყენებისა და ხელახლა დაკავშირების შემდეგ შეამოწმეთ კლიენტის ეფექტური რეზოლვერის კონფიგურაცია, შემდეგ გადაწყვიტეთ სახელი, რომელიც იცით, რომ მხოლოდ კერძო ზონაში არსებობს. dig intranet.example.net გამოკვეთილი სერვერის გარეშე გვიჩვენებს, რას იყენებს კლიენტი რეალურად. მას მოჰყევით მოთხოვნით იმ მისამართზე, რომელიც ამ ძიებამ დააბრუნა, რადგან გადაწყვეტა და სერვისზე წვდომა ცალკე ნაბიჯებია. ბრაუზერი, რომელიც საჯარო საიტებს DNS-over-HTTPS-ით ტვირთავს, არაფერს ამტკიცებს ოპერაციული სისტემის კერძო რეზოლვერის გზაზე. საჯარო მეორადი რეზოლვერიც არ არის უფლებამოსილი შიდა ზონისთვის.

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

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