შეცდომა 868 IP მისამართით? რას ხსნის Windows პირველად
დიალოგი ძებნის ჩავარდნას აცხადებს, თუმცა პროფილი რიცხვითი ჩანს. წაიკითხეთ პროფილის ნამდვილი ველი, შემდეგ გამოყავით სახელის პრობლემა ძველი ხელახალი დაკავშირების ხარვეზისგან.
დიალოგი აცხადებს, რომ სერვერის სახელის ამოხსნა ვერ მოხერხდა, ხოლო პროფილის ველი, რომელსაც უყურებთ, მისამართია. ეს კომბინაცია წინააღმდეგობა არ არის: კლიენტი ხსნის რაღაცას, რაც განსხვავდება იმ მნიშვნელობისგან, რომელსაც, თქვენი აზრით, ის კითხულობს. გაარკვიეთ, რას ურეკავს ის სინამდვილეში, სანამ დაასკვნით, რომ DNS გატეხილია. კლიენტის საკუთარი ნაბიჯების რიგი გიჩვენებთ, სად უნდა შეხედოთ.
კლიენტი სახელს ხსნის დარეკვამდე
Windows-ის მშობლიური VPN კავშირი კითხულობს თავის პროფილს, ხსნის სერვერის მისამართს, იწყებს გვირაბს და მხოლოდ ამის შემდეგ ახდენს ავთენტიფიკაციას. შეცდომა 868 მეორე ნაბიჯს ეკუთვნის. რადგან შემდგომი ნაბიჯები არასდროს სრულდება, დიალოგი შეიძლება სარეგისტრაციო მონაცემების პრობლემად გამოიყურებოდეს, როცა ძებნა პირველად ჩავარდა.
ეს რიგი სასარგებლოა, რადგან ავიწროებს შესამოწმებელ ფენას. როცა ერთი და იგივე პროფილი ერთი ქსელიდან მუშაობს და მეორიდან ვარდება, განსხვავება ჩვეულებრივ სახელის ამოხსნაშია და არა გვირაბის ტიპში ან ანგარიშში. შეამოწმეთ ძებნა იქ, სადაც ჩავარდნა ხდება, და არა იქ, სადაც პროფილი შეიქმნა.
რომელი სახელი, როცა ველი მისამართს აჩვენებს
წაიკითხეთ შენახული მნიშვნელობა ნაჩვენები სახელის ნაცვლად. კავშირის ეტიკეტი არ არის მისი სერვერის მისამართი, და მსგავსი ეტიკეტების ორი ჩანაწერი არასწორის კვალდაკვალ გგზავნით:
Get-VpnConnection -Name "Work VPN" |
Select-Object Name, ServerAddress, TunnelType
თუ პროფილი ყველა მომხმარებლისთვის მომზადდა, ჰკითხეთ ეს სფეროც ამით -AllUserConnection. შემდეგ ამოხსენით ზუსტად ის მნიშვნელობა, რომელიც ბრძანებამ დაბეჭდა, იმ ქსელიდან, სადაც ჩავარდნა ხდება. გამოიყენეთ ოპერატორის დოკუმენტირებული კარიბჭე და არა აპლიკაციის შიდა სახელი, რომელიც მხოლოდ გვირაბის აწევის შემდეგ იხსნება. ის მეორე მოთხოვნა მოსალოდნელი მიზეზით ვარდება და ზარის შესახებ არაფერს გეუბნებათ:
Resolve-DnsName vpn.example.com
როცა შენახული მნიშვნელობა ნამდვილად რიცხვითია, მოძებნეთ მეორე ადგილი, სადაც კლიენტი სახელს კითხულობს. EAP კონფიგურაცია შეიძლება მიუთითებდეს სერვერზე, სხვა ხელსაწყოდან იმპორტირებული პროფილი შეიძლება ატარებდეს საკუთარ მნიშვნელობას, და ადრინდელმა ინსტალატორმა შეიძლება დუბლირებული ჩანაწერი დატოვოს. დიალოგის ველი ყოველთვის ერთადერთი შეტანა არ არის.
Windows 7-ის ხელახალი დაკავშირების ნიმუში
ამ შეცდომის უკან მდგარი თემა აღწერს მანქანებს, რომლებიც ერთხელ დაუკავშირდნენ და შემდეგ უფრო გვიანდელ მცდელობაზე 868-ით ჩავარდნენ, პროფილში არაფრის შეცვლის გარეშე. მონაწილეებმა განაცხადეს, რომ Remote Access Connection Manager სერვისის ხელახლა გაშვება ან გასვლა და ხელახლა შესვლა დროებით აღადგენდა კავშირს. ეს გვერდის ავლის გზებია, არა დადასტურებული ძირეული მიზეზი.
მოეპყარით ამ ნიმუშს ცალკე ჰიპოთეზად. ხელახლა გაშვება აბრუნებს კლიენტის მდგომარეობას, ამიტომ შემდგომი დროებითი წარმატება არ ამტკიცებს, რომ DNS ჩანაწერი მცდარი იყო:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
წაიკითხეთ ცხრილი, როგორც განმასხვავებელი დაკვირვებების ნაკრები და არა დიაგნოზი. პირველი სტრიქონი სახელის პრობლემაა, მეორე კლიენტის მდგომარეობა, ხოლო მესამე პროფილი, რომელიც არასდროს ყოფილა სწორი. თითოეული განსხვავებულ ადამიანსა და განსხვავებულ შესწორებამდე მიგვიყვანს.
რა უნდა შევაგროვოთ ადმინისტრატორისთვის
ჩაწერეთ პროფილის სახელი, შენახული მისამართი, გვირაბის ტიპი, ქსელი, რომელზეც კლიენტი იყო, და გაგრძელდა თუ არა ჩავარდნა გათიშვის შემდეგ. ეს ჩანაწერი გამოყოფს ნამდვილ ძებნის ჩავარდნას ისტორიული ხელახალი დაკავშირების ქცევისგან, ვინმეს გამოცნობის საჭიროების გარეშე. შეინახეთ ასევე კლიენტის მოვლენების ჟურნალი მცდელობის ირგვლივ.
ძველი ნაგებობების გვერდის ავლის გზა მტკიცებაა, რომ ქცევა არსებობდა, და არა დაპირება, რომ იგივე სერვისის ხელახლა გაშვება მიმდინარე მანქანას გაასწორებს. დოკუმენტირებული ჰოსტის სახელის პირდაპირი მისამართით ჩანაცვლება არც შეკეთებაა.
ზოგი პროფილი მოელის სერვერის იდენტობას, რომელიც ემთხვევა კონფიგურირებულ სახელს, ამიტომ რიცხვითი გვერდის ავლის გზა შეიძლება ერთი შეცდომა მეორეთი გაცვალოს. თუ სახელი უნდა დარჩეს, შეასწორეთ ამოხსნის გზა და არა პროფილის ტექსტი. ნებისმიერ შემთხვევაში ჩაწერეთ, რა შეცვალეთ და რატომ.