L2TP/IPsec-ը ձախողվում է. առանձնացրեք IPsec-ը, թունելի նույնականացումը կամ PPP մուտքը
Անցեք նույնականացման երեք փուլերը հերթականությամբ, կանգ առեք այնտեղ, որտեղ մեկը ձախողվում է, և կարդացեք մատյանի այն տողը, որը նշում է շերտը՝ փոխարենը չփոխելով սխալ շերտի բանալին։
Մեկ L2TP/IPsec միացության մեջ երեք բան է նույնականացվում, և դրանցից միայն մեկն է ներգրավում հավաքող մարդուն։ IPsec-ը ապացուցում է թունելի ծայրակետերը, L2TP կառավարման միացումը կարող է կրկին ապացուցել գործընկերներին իր իսկ գաղտնիքով, իսկ PPP-ն այնուհետև ապացուցում է օգտվողի հաշիվը նստաշրջանի ներսում։ Ցանկացած փուլում ձախողումը հաճախորդի երկխոսության մեջ երևում է որպես ընդհանուր մուտքի սխալ, իսկ սերվերի մատյանում՝ բոլորովին այլ կերպ։ Անցեք փուլերը հերթականությամբ և կանգ առեք առաջին ձախողվողի մոտ, որովհետև չստուգված փուլից ներքև գտնվող ցանկացած փուլ նույնպես չստուգված է։
Նույնականացման երեք փուլ, երեք տարբեր ինքնություն
IPsec-ը ապացուցում է, թե ում են պատկանում ծայրակետերը՝ օգտագործելով նախապես համօգտագործված բանալի կամ վկայական։ Այդ ինքնությունը պատկանում է մեքենաներին կամ դարպասներին, երբեք՝ ստեղնաշարի մոտ նստած մարդուն։ Երբ գործընկերները այս փուլում չեն կարողանում համաձայնության գալ, ընդհանրապես ոչ մի L2TP փաթեթ չի փոխանակվում։
L2TP կառավարման միացումը կարող է ավելացնել երկրորդ՝ առանձին մարտահրավեր-պատասխան փոխանակում, որը ղեկավարվում է ընդհանուր գաղտնիքով, որը պետք է ունենան երկու ծայրերը։
RFC 2661-ը այդ կառավարման միացման նույնականացումը դարձնում է ընտրովի, ինչը բացատրում է, թե ինչու նույն սխալը տարբեր ախտանիշներ է առաջացնում երկու սերվերներում։ Այն տեղակայումը, որը երբեք չի կարգավորել թունելի գաղտնիք, ամբողջությամբ բաց է թողնում փուլը, իսկ այն, որը կարգավորել է միայն մի կողմում, ձախողվում է նախքան PPP-ի առաջարկվելը։ Այնուհետև PPP-ն նույնականացնում է օգտվողին PAP, CHAP կամ MSCHAPv2-ով և անունը փոխանցում է հաշիվների պահոցին, որը կարող է լինել տեղական, chap-secrets ֆայլում կամ RADIUS-ում։ Սխալ գաղտնաբառն այդ պահին դեռևս ձեզ թողնում է աշխատող թունել և ձախողված նստաշրջան։
Կարդացեք կանգառի կետը՝ նախքան կարգավորումը խմբագրելը
Սկսեք ipsec --version-ից, որպեսզի իմանաք՝ կարգավիճակի արտածումը strongSwan-ինն է, թե Libreswan-ինը։ Այնուհետև կարդացեք սերվերի մատյանը, ոչ թե հաճախորդի երկխոսությունը, որովհետև սերվերը գրանցում է, թե որ փուլն է մերժել։
Մեկ տողով սովորաբար լուծվում է տոմսը. IKE-ի կամ առաջարկների բողոքը առաջին փուլն է, կառավարման միացման հաղորդագրությունը՝ երկրորդը, իսկ PPP մեթոդի կամ հաշվի մերժումը՝ երրորդը։ Պատճենեք այդ տողը տոմսի մեջ՝ ժամանակի դրոշմանիշով։ Հաճախորդի կողմից գուշակելը վատնում է այն միակ ապացույցը, որ արդեն ունեք։
Բանալու նյութը և գաղտնաբառերը թողեք այդ տեղադրումից դուրս. փուլի անունն է ուղղորդում աշխատանքը, և արտահոսած նախապես համօգտագործված բանալին վերաբացում է տոմսը՝ ավելի վատ հետևանքներով։
Քայլ առաջին. IPsec-ն ունի՞ կապակցում։
Գործարկեք ipsec statusall-ը strongSwan-ում կամ ipsec whack --status-ը Libreswan-ում և փնտրեք հաստատված զավակ-կապակցում՝ ոչ զրոյական հաշվիչներով։ ip xfrm state-ը ցույց է տալիս միջուկի տեսքը երկուսում էլ։ Տեղադրված SA զույգը՝ աճող հաշվիչներով, նշանակում է, որ առաջին փուլն ավարտված է, և կարող եք առաջ գնալ։
Կապակցման բացակայությունն ընդհանրապես մատնանշում է գործընկերոջ հասցեն, առաջարկների հավաքածուն կամ նախապես համօգտագործված բանալին, իսկ երբեմն՝ սարք, որը վերագրում է UDP 500-ը՝ միաժամանակ գցելով UDP 4500-ը։ Կապակցումը, որը հաստատվում է և մի քանի վայրկյան անց անհետանում, սովորաբար երկու ծայրերի միջև կյանքի տևողության անհամապատասխանություն է, այլ ոչ թե հավատարմագրերի խնդիր։ Ստուգեք՝ արդյոք երկու կողմերն էլ թվարկում են նույն գաղտնագրման և հեշի առաջարկները, նախքան որևէ բան նորից մուտքագրելը։ Եթե ոչ, ոչ մի բանալի երբեք չի աշխատի։
Կանգ առեք, քանի դեռ կապակցումը բացակայում է։ PPP ընտրանքների խմբագրումն այդ պահին ոչինչ չի փոխում և թաքցնում է իսկական խափանումը հաջորդ մարդուց։
Քայլ երկրորդ. L2TP կառավարման միացումը նույնականացվե՞ց։
Երբ IPsec-ը աշխատում է, հետևեք L2TP դեմոնին՝ հաստատված վիճակի հասնող կառավարման միացման համար, քանի որ PPP-ն չի կարող սկսվել մինչ այդ։ Կառավարման միացման մերժումը նշանակում է, որ թունելի գաղտնիքը տարբերվում է ծայրերի միջև, կամ մի ծայրը պահանջում է գաղտնիք, որը մյուսը երբեք չի ուղարկում։ Հաճախորդները հաճախ ցուցադրում են shared secret պիտակով մեկ դաշտ, և այն սովորաբար պատկանում է IPsec-ին, այլ ոչ L2TP-ին։ Այն լրացնելը չի կարգավորում թունելի գաղտնիքը, իսկ մաքրելը չի անջատում այն։
Եթե ոչ մի կողմ չի կարգավորել թունելի գաղտնիք, բաց թողեք այս փուլը և կառավարման միացման ձախողումը համարեք հասանելիության խնդիր։ Հաստատեք, որ UDP 1701-ը հասնում է դեմոնին, և երկու ծայրերը համաձայն են նույն ինկապսուլյացիայի շուրջ։ Այդ երկու պայմաններից մեկի համար գրված հրապատի կանոնը կիսով բացվող միացման հաճախակի պատճառ է։
Միայն այն նստաշրջանն է իսկապես անցել թունելի փուլը, որը սկսում է բանակցել PPP-ի շուրջ։
Քայլ երրորդ. PPP-ն մերժո՞ւմ է հաշիվը։
PPP-ի ձախողումը դրսից այլ տեսք ունի. թունելը հաստատված է, նստաշրջանը սկսվում է, և դեմոնը գրանցում է նույնականացման մեթոդի ձախողում կամ հաշվի մերժում։ Կարդացեք այդ հաղորդագրության մեջ նշված մեթոդը։ PAP-ն և CHAP-ը ձախողվում են տարբեր պատճառներով, և այն սերվերը, որը մերժում է մեկը, կմերժի հաճախորդին, որն առաջարկում է միայն այդ մեկը։
Linux սերվերում ստուգեք այն ընտրանքների ֆայլը, որը դեմոնը փոխանցում է PPP-ին, սովորաբար /etc/ppp/options.xl2tpd, և հաստատեք, թե որ մեթոդներն են ընդունվում և որտեղ են լուծվում հաշիվները։ Անունը, որը կա RADIUS-ում, բայց չկա տեղական գաղտնիքների ֆայլում, մաքուր ձախողվում է և նմանվում է սխալ գաղտնաբառի։ Այնուհետև ստուգեք, որ հաճախորդն առաջարկում է մեթոդ, որն ընդունում է սերվերը, այլ ոչ ավելի ուժեղ մեկը, որը սերվերը մերժում է բանակցել։ Նախապես համօգտագործված բանալին փոխելը՝ այս փուլը վերանորոգելու համար, վատնում է կես օր և ոչինչ չի փոխում։
Երբ նստաշրջանը վերջապես բարձրանում է, հասցեների բաշխումը, DNS-ը և երթուղիները դեռ չեն ստուգվել, և յուրաքանչյուրը լուռ ձախողվում է իր ձևով։ Ձեր գրառումներում երեք շերտերն առանձին պահեք. ճիշտ բանալին սխալ հաշվի հետ միշտ ձախողվում է, և մի շերտի վերանորոգումը երբեք չի վերանորոգում մյուսը։