მოკლე შიდა სახელები VPN-ზე ვერ მუშაობს: სუფიქსი, რომელსაც ვერასდროს ხედავთ
მოკლე სახელი მხოლოდ იმიტომ მუშაობს, რომ ძიების სუფიქსი ავსებს მას. შეადარეთ სრული და მოკლე სახელი, რომ გამოყოთ სუფიქსის ნაკლი resolver-ის ხარვეზისგან.
მოკლე სახელი ოფისში მუშაობდა და VPN-ზე ვერ მუშაობს, მაშინ როცა სრული სახელი უპრობლემოდ იხსნება. არაფერი არ გატყდა. შიშველი სახელი, როგორიც intranet-ია, სრული სახელი არ არის; კლიენტი ამატებს სუფიქსს თავისი ძიების სიიდან და ითხოვს შედეგს. თუ VPN პროფილი არ აწვდის ამ სუფიქსს, ნაცნობი მოკლე ფორმა წყვეტს არსებობას.
ეს არის მთელი მითი. DNS არ გატყდა, ძიების პოლიტიკა შეიცვალა.
შიშველი სახელი სახელი არ არის
როცა ერთ იარლიყს აკრეფთ, resolver-მა უნდა გადაწყვიტოს რას ჰკითხოს. ის ცდის სახელს ისე, როგორც მოცემულია, შემდეგ სათითაოდ ამატებს ძიების სიის ჩანაწერებს, სანამ რაღაც უპასუხებს. Linux-ზე resolv.conf ამატარებს ამ თანმიმდევრობას search და ndots პარამეტრებით. Windows-ზე სუფიქსების სია და სახელების ამოხსნის პოლიტიკა იგივეს აკეთებს. მოაშორეთ სუფიქსი და resolver-ს დასამატებელი აღარაფერი ექნება.
ამიტომ მომუშავე მოკლე სახელი პოლიტიკის მტკიცებულებაა, არა ჯანსაღი DNS სერვერის.
რას აკეთებს სუფიქსების სია და resolver-ის მისამართი
ეს ორი მუდმივად ერევა ერთმანეთს. resolver-ის მისამართი ამბობს ვის ჰკითხოთ; სუფიქსების სია ამბობს რომელი სახელის შესახებ ჰკითხოთ. VPN-ს შეუძლია მოგცეთ კერძო resolver სუფიქსის გარეშე, ან სუფიქსი არასწორ resolver-თან. ამ ხარვეზებიდან მხოლოდ ერთი ჰგავს DNS-ის შეწყვეტას.
შეამოწმეთ ისინი ცალ-ცალკე, რადგან არასწორის გასწორება ხარჯავს მხარდაჭერის ფანჯარას.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
სამი სიმპტომი, სამი განსხვავებული პასუხისმგებელი.
ჯერ სრული სახელი გამოსცადეთ
მოითხოვეთ ადმინისტრატორის დოკუმენტირებული სრულად კვალიფიცირებული სახელი, არა ვარაუდი. მომუშავე FQDN ამტკიცებს, რომ resolver მისაწვდომია და ჩანაწერი არსებობს, რაც ერთი მოთხოვნით ხსნის შესაძლო მიზეზების ნახევარს. გამოიყენეთ ხელსაწყო, რომელიც აჩვენებს რომელი სერვერი უპასუხა, რომ ქეშირებული შედეგი არ წაიკითხოთ.
ტესტი დახურული შეინახეთ. შიდა ვარიანტების საჯარო resolver-ზე გაგზავნა ამჟღავნებს სახელებს და ამოწმებს პოლიტიკას, რომელიც არავის განუზრახავს.
სად ეკუთვნის გასწორება
გაასწორეთ მფლობელი პროფილი ან მისი შემქმნელი მართვის სისტემა. ლოკალური resolver-ის კონფიგურაციის ხელით შეცვლა ჩვეულებრივ ქრება ხელახლა დაკავშირებისას, ან ვრცელდება ყველა ქსელზე, რომელსაც მოწყობილობა უერთდება, რაც უარესია.
Windows-ზე შეამოწმეთ მოქმედი პოლიტიკა და არა დამახსოვრებული მოსანიშნი უჯრა. Get-DnsClientNrptPolicy აჩვენებს რეალურად მოქმედ სახელების ამოხსნის წესებს.
macOS-ზე scutil --dns ბეჭდავს resolver-ის კონფიგურაციას თითოეული სკოპირებული ინტერფეისისთვის, მათ შორის VPN-ის მიერ გაგზავნილ ძიების დომენებს.
Linux-ზე წაიკითხეთ search სტრიქონი /etc/resolv.conf-ში, მაგრამ შეამოწმეთ გადაწერა თუ არა VPN კლიენტმა. თუ ფაილი იმართება, დაარედაქტირეთ ჭეშმარიტების წყარო და არა რენდერებული ფაილი. წინა ქსელიდან დარჩენილი მოძველებული search სტრიქონი გავრცელებული მიზეზია.
რა შეინახოთ პროფილთან ერთად
შეინახეთ გასწორებული სრული სახელი, სუფიქსების სია და resolver-ის მისამართი კლიენტის პროფილის გვერდით. შემდეგი ადამიანი, რომელიც შეატყობინებს, რომ intranet საიტი არ მუშაობს, შეძლებს სამი ცნობილი მნიშვნელობის შედარებას ცარიელი გვერდიდან დაწყების ნაცვლად.
და თუ მხოლოდ მოკლე ფორმა ვერ მუშაობს, დაწერეთ ეს ბილეთში. ეს წინადადება resolver-ის გუნდს შუადღეს უზოგავს.