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Կարդացեք ցանկը հասցեների լուծման կապման և երրորդ կողմի զտիչների համար։ Անջատված կապումը նպատակային վերանորոգում է, մինչդեռ զտիչի առկայությունը հարց է այդ ծրագրի սեփականատիրոջը, ոչ թե անվտանգության արտադրանքը անջատելու թույլտվություն։ Բոլոր ադապտերները ջնջելը միակ քայլն է, որը ոչնչացնում է այն ապացույցները, որոնք ձեզ պետք կգան, եթե ձախողումը վերադառնա։
Ուղղումից հետո նորից փորձեք նույն պրոֆիլը, ապա կրկնեք երկու հաճախորդի դեպքը, եթե դա էր սկզբնական ախտանիշը, որովհետև հաջող առաջին կապը թաքցնում է հատկացման խնդիրը, որը բացահայտում է երկրորդ հաճախորդը։ Նշումը պահեք չորս դաշտում՝ որ հաճախորդը, որ կապումը, որ իրադարձությունը և ինչ փոխվեց։ Փորձից փորձ փոխեք մեկ շերտ, քանի որ հաճախորդի ուղղումը և լողավազանի փոփոխությունը միասին կիրառելու դեպքում հնարավոր չէ վերագրել, և հաջորդ ձախողումը նոր տեսք կունենա, թեև նույնն է։