რატომ ხსნის MagicDNS მოწყობილობებს, მაგრამ არა ოფისის ჰოსტების სახელებს

MagicDNS ყოველ მოწყობილობას tailnet-ში აძლევს სახელს, რომელიც მისი მანქანის სახელისა და tailnet-ის DNS დომენისგან მიიღება. ამ სახელს Tailscale ქმნის და მასზე პასუხი Tailscale-ის ხსნარის გზით მოდის. ოფისის ჰოსტის სახელი, მაგალითად files.office.example, ეკუთვნის ზონას, რომელიც Tailscale-ს არასდროს დაუწერია, ამიტომ მოწყობილობის გადარქმევა ვერ შექმნის მას. ორი სახელთა სივრცე ერთად არსებობს; უბრალოდ სხვადასხვა მფლობელი აქვთ.

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

ორი სახელთა სივრცე, ორი მფლობელი

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

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

მიმართეთ ოფისის ზონა მის ხსნარზე

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

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

ხელმისაწვდომობა ხსნამდე მოდის

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

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

გამოყავით სახელის უკმარისობა სერვისის უკმარისობისგან

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

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

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