რატომ ითარგმნება სერვერის სახელი VPN მისამართში აკრეფის შემდეგ

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

ორი მისამართი, ერთი სახელი, სამი პირობა

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

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

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

წაიკითხეთ ჩანაწერი, სანამ შეცვლით რეგისტრატორს

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

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

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

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

გაასწორეთ გამომქვეყნებელი ან ჩანაწერი, მაგრამ იცოდეთ რომელი

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

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

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

შეამოწმეთ წარუმატებელი კლიენტის ქსელიდან

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

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

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

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