Windows-ის VPN შეცდომა 720: მისამართების აუზი თუ კლიენტის მიბმა?
შეცდომა 720 ნიშნავს, რომ კავშირს არასოდეს მიუღია გამოსაყენებელი მისამართი. გამოყავით ერთ ჰოსტზე არსებული ხარვეზები მრავალ ჰოსტზე არსებული ხარვეზებისგან, სანამ ადაპტერს ხელახლა დააყენებთ.
შეცდომა 720 ჩნდება სერტიფიკატების მიღების შემდეგ და სწორედ ამიტომ აბრუნებს ადამიანებს პაროლის ველთან. კავშირი მიაღწია იმ წერტილს, სადაც მისამართი მოლაპარაკდება და ვერ მიიღო. ორი სრულიად განსხვავებული ხარვეზი ქმნის იმავე დიალოგს: სერვერს გასაცემი არაფერი ჰქონდა ან სწორედ ამ კლიენტმა ვერ დაასრულა მოლაპარაკება. ამ ორის გამოყოფა რაიმეზე შეხებამდე შეკეთების უდიდესი ნაწილია და გამოყოფა დოკუმენტირებულია Microsoft-ის 720 შეცდომის პრობლემების მოგვარების გვერდზე.
რასაც დიალოგი არ ამბობს
შეტყობინება აღწერს PPP მოლაპარაკების ხარვეზს და განზრახ ბუნდოვანია, რადგან კლიენტი ვერ ხედავს, რატომ უარყო სერვერმა. ეს არ არის სერტიფიკატების შეცდომა და არ არის განაცხადი გვირაბის დაშიფვრაზე. ეს ნიშნავს, რომ მისამართი ან მოლაპარაკების პარამეტრები არ მიწოდებულა.
სერვერის მხარეს ჩვეულებრივი მიზეზი განაწილებაა: სტატიკური RRAS აუზი თავისუფალი მისამართების გარეშე ან DHCP კონფიგურაცია, რომლის დიაპაზონიც ამოწურულია ან მიუწვდომელია, ზუსტად ამ სიმპტომს იძლევა ყველა კლიენტში, რომელიც ცდილობს. კლიენტის მხარეს ჩვეულებრივი მიზეზი მიბმაა. PPP-ის მატარებელი WAN Miniport სწორ კომპონენტებთან უნდა იყოს მიბმული და გამორთული მიბმა ან ჩასმული ქსელური ფილტრი შეიძლება აჩერებდეს მოლაპარაკებას ხილული მოწყობილობის პრობლემის გარეშე. ამ ორ ოჯახს განსხვავებული მტკიცებულებები სჭირდება და მათ შორის არჩევის ყველაზე სწრაფი გზა რამდენი კლიენტია დაზარალებული იმის დათვლაა.
ჯერ პოპულაცია გაყავით, შემდეგ აუზი
დათვალეთ დაზარალებული კლიენტები ნებისმიერი კონფიგურაციის წაკითხვამდე. ხარვეზი, რომელიც ყველას ერთდროულად ურტყამს, სერვერის მდგომარეობაა, ხოლო ხარვეზი, რომელიც ერთ მანქანას მიჰყვება ქსელებს შორის, კლიენტის მდგომარეობაა. ეს დათვლა ჩატის არხში ერთ შეტყობინებად ღირს და ნახევარ დღეს ზოგავს.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
შემდეგ დაუკავშირეთ ერთი წარუმატებელი მცდელობა სერვერის საკუთარ ჩანაწერს, რადგან RRAS აღრიცხავს მოვლენას, როცა ვერ ანაწილებს და ეს მოვლენა ხარვეზს ასახელებს და არა სიმპტომს. თუ ხარვეზი კონკრეტულ კლიენტს მიჰყვება, სერვერის ჟურნალი ამ მცდელობისთვის არაფერს აჩვენებს, რაც თავისთავად ინფორმაციულია. განაწილების შეცდომის არარსებობა პრობლემას ამ კლიენტის მოლაპარაკებამდე ავიწროებს და გეუბნებათ, რომელი ბრძანებები შეასრულოთ შემდეგ.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }წაიკითხეთ სერვერის განაწილების მდგომარეობა
RRAS-ის მხარეს დაადასტურეთ, რომელი განაწილების მეთოდია რეალურად კონფიგურირებული და არა რომელი ვარაუდობს დოკუმენტაცია. სტატიკური აუზი და DHCP-ით გადაცემული კონფიგურაცია სხვადასხვაგვარად ფუჭდება და შესწორება ეკუთვნის იმას, რაც გამოიყენება. სტატიკურ აუზში დათვალეთ თავისუფალი მისამართები და მოძებნეთ მომხმარებლის მიხედვით განაწილებები, რომლებიც ინახავენ იჯარას, რომელიც არავის ახსოვს, რადგან დიდად შესახედავი აუზი შეიძლება სრულად დაკავებული იყოს. DHCP-ისთვის შეამოწმეთ, რომ რელე აღწევს სერვერს და რომ დიაპაზონში თავისუფალი იჯარებია.
ჩვეულებრივი კლიენტებით ამოწურული დიაპაზონი იძლევა იმავე 720-ს, რასაც არასწორად კონფიგურირებული აუზი და RRAS-ის კონსოლი ორივე შემთხვევაში სრულიად ჯანმრთელად გამოიყურება. წინააღმდეგობა გაუწიეთ მემკვიდრეობით მიღებულ გვერდის ავლის ხერხს აუზის პატარა დიაპაზონებად დაყოფის შესახებ: საწყისი რჩევა ერთი ადმინისტრატორის შედეგს აღწერდა და არ ასწორებს განაწილების ხარვეზს, რომელსაც თვით სერვერის მოვლენებს შეუძლიათ პირდაპირ დაასახელონ.
წაიკითხეთ კლიენტის მიბმები მათი დაუმსხვრევად
თუ მტკიცებულებები ერთ კლიენტზე მიუთითებს, შეამოწმეთ დამალული ადაპტერი და არა ხელახლა დააყენოთ სტეკი. პირველი ბრძანება ჩამოთვლის WAN Miniport ინტერფეისებს და მათ სახელებს; მეორე იღებს სახელს, რომელიც მან დააბრუნა და არა სახელმძღვანელოდან გადაწერილს.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsწაიკითხეთ სია მისამართების გადაწყვეტის მიბმისა და მესამე მხარის ფილტრებისთვის. გამორთული მიბმა მიზანმიმართული შეკეთებაა, ხოლო ფილტრის არსებობა კითხვაა იმ პროგრამული უზრუნველყოფის მფლობელისთვის და არა ნებართვა უსაფრთხოების პროდუქტის გამორთვაზე. ყველა ადაპტერის წაშლა ერთადერთი ნაბიჯია, რომელიც ანადგურებს მტკიცებულებებს, რომლებიც დაგჭირდებათ, თუ ხარვეზი დაბრუნდება.
შესწორების შემდეგ ხელახლა სცადეთ იგივე პროფილი და შემდეგ გაიმეორეთ ორი კლიენტის შემთხვევა, თუ ეს იყო საწყისი სიმპტომი, რადგან წარმატებული პირველი კავშირი მალავს განაწილების პრობლემას, რომელსაც მეორე კლიენტი ავლენს. შეინახეთ ჩანაწერი ოთხ ველში: რომელი კლიენტი, რომელი მიბმა, რომელი მოვლენა და რა შეიცვალა. ყოველ მცდელობაზე შეცვალეთ ერთი ფენა, რადგან ერთად გამოყენებული კლიენტის შესწორება და აუზის ცვლილება ვერ მიეწერება და შემდეგი ხარვეზი იგივე რომ იყოს, ახლად გამოჩნდება.