Windows VPN xətası 720: ünvan hovuzu, yoxsa müştəri bağlantısı?
Xəta 720 o deməkdir ki, bağlantıya heç vaxt istifadəyə yararlı ünvan verilməyib. Adapteri yenidən quraşdırmadan əvvəl bir hostdakı nasazlıqları çox hostdakı nasazlıqlardan ayırın.
Xəta 720 etimadnamələr qəbul edildikdən sonra görünür və buna görə insanları parol sahəsinə qaytarır. Bağlantı ünvanın razılaşdırıldığı nöqtəyə çatdı və heç bir ünvan almadı. İki çox fərqli nasazlıq eyni dialoqu yaradır: serverin paylaşacaq heç nəyi yox idi, ya da məhz bu müştəri razılaşmanı tamamlaya bilmədi. Bu ikisini hər hansı bir şeyə toxunmadan ayırmaq təmirin böyük hissəsidir və ayrım Microsoft-un 720 xətası üzrə problem həlli səhifəsində sənədləşdirilib.
Dialoqun susduğu şeylər
Mesaj PPP razılaşmasındakı nasazlığı təsvir edir və qəsdən qeyri-müəyyəndir, çünki müştəri serverin niyə imtina etdiyini görə bilmir. Bu, etimadnamə xətası deyil və tunelin şifrələnməsi barədə ifadə deyil. Ünvanın və ya razılaşma parametrlərinin çatdırılmadığını bildirir.
Server tərəfində adi səbəb təyin etmədir: boş ünvanı olmayan statik RRAS hovuzu və ya əhatəsi tükənmiş və ya əlçatmaz olan DHCP konfiqurasiyası cəhd edən hər müştəridə məhz bu simptomu yaradır. Müştəri tərəfində adi səbəb bağlantıdır. PPP daşıyan WAN Miniport düzgün komponentlərə bağlanmalıdır və söndürülmüş bağlantı və ya daxil edilmiş şəbəkə filtri görünən cihaz problemi olmadan razılaşmanı dayandıra bilər. İki ailə fərqli sübutlara ehtiyac duyur və aralarında seçim etməyin ən sürətli yolu neçə müştərinin təsirləndiyini saymaqdır.
Əvvəlcə populyasiyanı, sonra hovuzu ayırın
Hər hansı konfiqurasiyanı oxumazdan əvvəl təsirlənmiş müştəriləri sayın. Hamını eyni anda vuran nasazlıq server vəziyyətidir, bir maşını şəbəkələr arasında izləyən nasazlıq isə müştəri vəziyyətidir. Bu sayım bir söhbət kanalında bir mesaja başa gəlir və bir günortanı qənaət edir.
| 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 |
Sonra uğursuz bir cəhdi serverin öz qeydi ilə əlaqələndirin, çünki RRAS təyin edə bilmədikdə hadisə qeyd edir və bu hadisə simptomu deyil, nasazlığı adlandırır. Nasazlıq konkret bir müştərini izləyirsə, server jurnalı həmin cəhd üçün heç nə göstərməyəcək, bu da özlüyündə məlumatvericidir. Təyinat xətasının olmaması problemi həmin müştəridəki razılaşmaya daraldır və bundan sonra hansı əmrləri işlədəcəyinizi deyir.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Serverin təyinat vəziyyətini oxuyun
RRAS tərəfində sənədləşmənin fərz etdiyi metodu deyil, həqiqətən hansı təyinat metodunun konfiqurasiya edildiyini təsdiqləyin. Statik hovuz və DHCP vasitəsilə ötürülən konfiqurasiya fərqli şəkildə uğursuz olur və düzəliş istifadədə olana aiddir. Statik hovuzda boş ünvanları sayın və heç kimin xatırlamadığı icarə saxlayan istifadəçi üzrə təyinatları axtarın, çünki böyük görünən hovuz tam dolu ola bilər. DHCP-də relayın serverə çatdığını və əhatədə boş icarələr olduğunu yoxlayın.
Adi müştərilər tərəfindən tükənmiş əhatə səhv konfiqurasiya edilmiş hovuzla eyni 720-ni yaradır və RRAS konsolu hər iki halda tamamilə sağlam görünəcək. Hovuzu daha kiçik aralıqlara bölmək barədə miras qalmış keçici həllə qarşı durun: ilkin məsləhət bir administratorun nəticəsini təsvir edirdi və serverin öz hadisələrinin birbaşa adlandıra biləcəyi təyinat nasazlığını aradan qaldırmır.
Müştərinin bağlantılarını pozmadan oxuyun
Sübutlar bir müştərini göstərirsə, steki yenidən quraşdırmaq əvəzinə gizli adapteri yoxlayın. Birinci əmr WAN Miniport interfeyslərini və adlarını sadalayır; ikincisi qaytardığı adı götürür, təlimatdan köçürülmüş adı deyil.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsSiyahını ünvan həlli bağlantısı və üçüncü tərəf filtrləri baxımından oxuyun. Söndürülmüş bağlantı məqsədli təmirdir, filtrin olması isə həmin proqram təminatının sahibinə sualdır, təhlükəsizlik məhsulunu söndürmək icazəsi deyil. Bütün adapterləri silmək nasazlıq qayıdarsa ehtiyac duyacağınız sübutları məhv edən yeganə addımdır.
Düzəlişdən sonra eyni profili yenidən sınayın və bu ilkin simptom idisə iki müştəri halını təkrarlayın, çünki uğurlu ilk bağlantı ikinci müştərinin aşkar etdiyi təyinat problemini gizlədir. Qeydi dörd sahədə saxlayın: hansı müştəri, hansı bağlantı, hansı hadisə və nə dəyişdi. Cəhd başına bir qat dəyişin, çünki birlikdə tətbiq edilən müştəri düzəlişi və hovuz dəyişikliyi aid edilə bilməz və növbəti nasazlıq eyni olsa da yeni görünəcək.