L2TP/IPsec սխալ 789, 720 կամ 691՝ նախ ուղղեք ճիշտ փուլը

Windows 11-ը տարբեր համար է հաղորդում L2TP/IPsec-ի յուրաքանչյուր փուլի համար, և այդ համարը նշում է փուլ, այլ ոչ թե գնահատում ձախողումը։ 789-ը ձախողվում է մինչև PPP կապի գոյությունը, 720-ը ձախողվում է կապի բարձրացման ընթացքում, իսկ 691-ը ձախողվում է այն բանից հետո, երբ կապը բարձրացել է, և հավատարմագրերը մերժվել են։ Օգտակար որոշումը ոչ թե այն է, թե որ ուղղումն է ամենատարածվածը, այլ այն, թե որ փուլն է ծածկագիրը վկայում, որ դուք հասել եք։ Կարդացեք դա նախ, ապա յուրաքանչյուր փորձի ընթացքում փոխեք մեկ շերտ, որպեսզի հաջորդ ծածկագիրը ձեզ դեռ ինչ-որ բան ասի։

Կարդացեք ծածկագիրը որպես փուլ, ոչ որպես խափանումների ցանկ

L2TP միացումը հատում է երեք սահման ֆիքսված հերթականությամբ։ IKE-ն UDP 500-ի վրայով բանակցում է անվտանգության ասոցիացիաների շուրջ, NAT-ի անցումը տեղափոխում է այդ տրաֆիկը UDP 4500, և միայն դրանից հետո L2TP թունելը կրում է PPP նստաշրջան, որը նույնականացնում է օգտատիրոջը և նշանակում հասցե։

Այդ հերթականությունն է պատճառը, որ փոփոխվող սխալի ծածկագիրը օգտակար ապացույց է։ 789-ից 720 անցումը նշանակում է, որ IPsec-ն այժմ բանակցում է, և ձախողումը տեղափոխվել է կապի կառուցմանը։ 720-ից 691 անցումը նշանակում է, որ կապը բարձրացել է, և դարպասը մերժել է ինքնությունը։ Եթե հինգ ուղղում կիրառեք միանգամից, կկորցնեք այդ ազդանշանը և չեք կարողանա ասել, թե որ փոփոխությունն է աշխատել։

789՝ ընտրեք ուղու և տեղական քաղաքականության միջև

789 ծածկագիրը մշակման սխալ է սկզբնական անվտանգության բանակցությունների ընթացքում։ IPsec-ը երբեք օգտագործելի ասոցիացիա չի ստեղծել, ուստի հաշիվը դեռ չի փորձարկվել։ Սկսեք ուղուց և համօգտագործվող բանալուց, ոչ թե հաշվից։

Հաստատեք, որ UDP 500-ը և UDP 4500-ը հասնում են սերվերին, և որ նախապես համօգտագործվող բանալին համընկնում է բայթ առ բայթ՝ ներառյալ մեծատառի և փոքրատառի տարբերությունը և վերջին բացատները։ Եթե սերվերը NAT-ի հետևում է, Windows-ին կարող է անհրաժեշտ լինել նաև փաստաթղթավորված գրանցամատյանի արժեքը։ Օգտագործեք 1, երբ սերվերը NAT-ի հետևում է, և 2, երբ երկու ծայրերն էլ են, ապա վերագործարկեք, քանի որ քաղաքականության գործակալը արժեքը կարդում է գործարկման պահին:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

Ադապտերի ավելի ծանր վերանորոգումը պատկանում է մյուս ճյուղին։ Wi-Fi սարքի և WAN մինիպորտերի հեռացումը, ապա սարքաշարի կրկնակի սկանավորումը արդարացված է, երբ տեղական IPsec կույտն ինքն է վնասված, և VPN-ի այլ տեսակներ նույն կերպ ձախողվում են։ Դա իզուր ջանք է, երբ ձախողվում է միայն մեկ L2TP սերվեր, մինչդեռ ցանցի մյուս բոլոր ուղիներն աշխատում են։

720՝ ընտրեք այս ադապտերի և սերվերների լողավազանի միջև

720 սխալը հաղորդում է, որ հեռավոր համակարգչի հետ կապը չհաջողվեց հաստատել, և այն հայտնվում է IPsec-ի հաջողությունից հետո։ Թունելը հասավ միջերեսը բարձրացնելու կամ հասցե ստանալու կետին, ապա կանգ առավ։ Դա այն դարձնում է տեղական ադապտերի հարց կամ սերվերի հզորության հարց։

Որոշման համար օգտագործեք ազդեցության շառավիղը։ Մեկ Windows մեքենայի ձախողումը մատնանշում է վատ WAN մինիպորտ, կանգնեցված Remote Access ծառայություն կամ վնասված միացման պրոֆիլ։ Մի քանի հաճախորդների միաժամանակյա ձախողումը մատնանշում է սերվերը՝ սպառված հասցեների լողավազան, կանգնեցված RRAS ծառայություն կամ լողավազան, որն այլևս չի համապատասխանում հաճախորդի ենթացանցին։ Ուղղեք այն կողմը, որը ցույց է տալիս օրինաչափությունը, նախքան մյուսը փոխելը։

Մեկ հաճախորդի ճյուղում մեկ անգամ հեռացրեք WAN մինիպորտերը և սկանավորեք սարքաշարի փոփոխությունները, ապա վերագործարկեք և նորից փորձեք։ Սերվերի ճյուղում ստուգեք լողավազանը և ծառայության վիճակը, ոչ թե հաճախորդը, քանի որ աշխատող ադապտերի վերատեղադրումը չի կարող ստեղծել հասցե, որը սերվերը չունի։

691՝ ընտրեք հավատարմագրի և կանգնեցված օգնականի միջև

691 ծածկագիրը նույնականացման մերժում է, և այն ամենահաճախ սխալ ընկալվող ծածկագիրն է որպես սխալ գաղտնաբառ։ Թունելը բարձրացված է, դարպասը տեսել է ինքնություն և մերժել է այն։ Պատճառը դեռ կարող է լինել գաղտնաբառի դաշտից դուրս։

Նախ ստուգեք տիրույթի դաշտը, ապա գաղտնաբառի ճշգրիտ նշանները։ Բացատ, չակերտ կամ shell-ի հատուկ նշան պարունակող գաղտնաբառը կարող է աղավաղվել մինչև սերվեր հասնելը. Linux-ում pppd հաղորդում է նույն մերժումը, ինչ E=691 չակերտազուրկ արժեքի կամ բացակայող տիրույթի դեպքում։ Կրկնակի մուտքագրեք գաղտնիքը՝ փոխանակ այն տեղադրելու, և ջնջեք ցանկացած պահված հավատարմագիր, որը կարող է հին արժեք պարունակել։

Մարդկանց բաց թողած ճյուղը կանգնեցված օժանդակ ծառայությունն է։ Երբ մատակարարի հաճախորդը կախված է իր սեփական ծառայությունից՝ հավատարմագրերը դարպասին փոխանցելու համար, անջատված կամ վթարված ծառայությունը ստեղծում է 691, նույնիսկ երբ գաղտնաբառը ճիշտ է։ Ստուգեք մատակարարի ծառայության վիճակը հաշիվը վերականգնելուց առաջ, հատկապես վերագործարկումից կամ թարմացումից հետո։

Ճյուղերը տարանջատելու համար փորձարկեք նույն օգտանունը աշխատող մեկ այլ VPN պրոֆիլի կամ RADIUS փորձնական հաշվի վրա։ Եթե դա հաջողվի, հավատարմագիրը լավն է, և տեղական հաճախորդի ուղին կասկածելի է։ Եթե այն նույն կերպ ձախողվի, խնդիրը հաշիվն է կամ դարպասի քաղաքականությունը։

Փոխեք մեկ շերտ յուրաքանչյուր փորձի ընթացքում

Աշխատեք դրսից ներս՝ հասանելիություն և NAT անցում, ապա նախապես համօգտագործվող բանալին, ապա տեղական ադապտերի կույտը, ապա հավատարմագիրը, ապա սերվերների լողավազանը և ծառայությունները։ Այդ հերթականությունը հետևում է ծածկագրերի նկարագրած փուլերին և յուրաքանչյուր արդյունք վերագրելի է պահում մեկ փոփոխության։

Պահեք կարճ մատյան ծածկագրի մասին յուրաքանչյուր փորձից առաջ և հետո, հաճախորդի կառուցվածքի մասին և այն մասին, թե արդյոք փոխվել է սերվերը կամ հաճախորդը։ 789, ապա 720, ապա 691 հաջորդականությունը առաջընթացի քարտեզ է. նույն ծածկագիրը երկու անգամ նշանակում է, որ վերջին փոփոխությունը չի անդրադարձել այդ փուլին։ Windows-ի վերատեղադրումը ջնջում է այս քարտեզը և հազվադեպ ուղղում է դարպասում ապրող ձախողումը։

Երբ ծածկագիրը դադարում է փոխվել, դադարեցրեք իրերը փոխելը։ Գրանցեք ընթացիկ ծածկագիրը, սերվերի հասցեն, նույնականացման մեթոդը և փորձի ժամը, ապա համեմատեք այդ գրառումը աշխատող հաճախորդի հետ։ Երկու գրառումների միջև տարբերությունը սովորաբար ավելի փոքր է, քան այն ուղղումների ցանկը, որ մարդիկ լռելյայն փորձում են։