OpenVPN DNS-ს აგზავნის, მაგრამ რეზოლვერმა შესაძლოა ის ვერასდროს დაინახოს

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

სიმპტომი: ჟურნალი DNS-ს აჩვენებს, სახელები კი მაინც ვერ იხსნება

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

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

მიღება ჯერ არ ნიშნავს გამოყენებას

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

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

იპოვეთ რეზოლვერის მფლობელი პლატფორმის მიხედვით

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

წაიკითხეთ ფაქტობრივი მდგომარეობა იმ ხელსაწყოთი, რომელიც ნამდვილად პასუხობს მოთხოვნებს: resolvectl query internal.example.net systemd-resolved ჰოსტზე, ან პლატფორმის ეკვივალენტით. შემდეგ შეადარეთ ეს პასუხი იმ DNS სერვერს, რომელიც კლიენტის ჟურნალის მიხედვით გაიგზავნა.

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

სკრიპტები და foreign_option

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

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

გამოსცადეთ სახელი და არა ჟურნალი

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

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