NXDOMAIN VPN-ის გავლით ტუნელის გათიშვას არ ნიშნავს

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

რას ამტკიცებს პასუხი სინამდვილეში

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

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

მითი: პირადი სახელის არარსებობა ნიშნავს, რომ ტუნელი ჩავარდა

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

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

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

ჰკითხეთ სწორ გამხსნელს სწორი სახელით

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

უარყოფითი ქეშირება ხსნის შეკეთების შემდგომ დაყოვნებას

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

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

გამოყავით სახელი გზისგან

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

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