გვირაბი მუშაობს, მაშინ რატომ არ სრულდება კერძო სახელი?

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

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

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

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

გამოიყენეთ მისამართი, რომელზეც ღრუბლოვანი ქსელი ნამდვილად პასუხობს

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

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

გვირაბი სახელთა სივრცეს არ ატარებს

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

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

საზღვრები რიგით გაიარეთ

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

ჩაწერეთ, რომელი ნაბიჯი ჩაიშალა. ეს ერთი ხაზია ის, რაც შემდეგ ადამიანს სჭირდება, და მისი ჩაწერა ათ წამს იღებს.

შეინახეთ ჯაჭვი იქ, სადაც შემდეგი ადამიანი იპოვის

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

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