Ինչու միայն PPP CHAP-ը չի կարող բավարարել MPPE-ի պահանջը

Գաղտնագրում պահանջող PPTP պրոֆիլը սովորաբար ձախողվում է նույն տեղում՝ PPP-ն համաձայնում է նույնականացման փոխանակման շուրջ, որը երբեք չի արտադրում MPPE-ին անհրաժեշտ բանալիների նյութը։ Թունելը կիսակենդանի է թվում, գաղտնաբառն ընդունվում է, և կապը կտրվում է նախքան որևէ երթևեկություն այն հատելը։ CHAP-ի բացվող ցանկին դիմելը, մինչև ինչ-որ բան միանա, թաքցնում է իրական թերությունը, և դա պայմանագիր է նույնականացման եղանակի ու պաշտպանության քաղաքականության միջև։ Ստորև բերված ստուգումները դասավորված են այնպես, որ յուրաքանչյուրը բացառում է հաջորդից ավելի էժան պատճառ։

Մեկ PPTP կապի ներսում երկու բանակցություն է ընթանում

PPTP-ն սովորական PPP նստաշրջան է տեղափոխում GRE թունելի ներսում, և երկուսը բանակցում են առանձին։ Արտաքին շերտը որոշում է, թե ինչպես են փաթեթները փաթեթավորվում և որ կառավարման ուղին գոյություն ունի՝ ներքին PPP նստաշրջանը որոշում է, թե ով է զուգընկերը և ինչ պաշտպանություն է նստում վերևում։ Ուստի գաղտնաբառի հարցումը որևէ բան ապացուցում է միայն ներքին շերտի մասին, իսկ ավարտված արտաքին ձեռքսեղմումը ոչինչ չի ապացուցում դրանցից ոչ մեկի մասին։ Պրոֆիլներն այստեղ ձախողվում են, որովհետև մարդիկ վրիպազերծում են թունելը, մինչ տարաձայնությունը նստած է PPP-ի ներսում։

Սովորական CHAP-ը RFC 1994-ի մարտահրավեր-պատասխան փոխանակումն է՝ կառուցված ընդհանուր գաղտնիքի և ոչ այլ բանի վրա։ MS-CHAPv2-ը այլ հաղորդագրություններով և այլ ելքով մեկ այլ փոխանակում է, ստանդարտացված RFC 2759-ում։ Երկու անունների ընդհանուր բառը միակ բանն է, ինչ նրանք ընդհանուր ունեն լարի վրա։ Անուններից ոչ մեկը չի ասում, թե ինչ է արտադրում փոխանակումը, և դա է միակ կարևոր մասը։

Այդ պատճառով պարզապես CHAP պիտակավորված տարբերակը երկիմաստ է հին պրոֆիլում։ Երբ սերվերը ցանկանում է MS-CHAPv2, իսկ հաճախորդն առաջարկում է սովորական CHAP, կապի կառավարումը դեռ կարող է ավարտվել, և գաղտնաբառը դեռ կարող է ընդունվել։ Ձախողումը գալիս է ավելի ուշ, երբ սերվերը փորձում է պաշտպանության բանալիներ ստանալ փոխանակումից, որն ոչինչ չի արտադրել։

Համապատասխանեցրեք պահանջվող եղանակը այն բանալիներին, որոնք այն կարող է արտադրել

MPPE բանալիները PPP-ի ընդհանուր հատկություն չեն։ Microsoft CHAP ընտանիքի համար ածանցումը նշված է RFC 3079-ում, և այն որպես մուտք վերցնում է MS-CHAP փոխանակման ելքը, այլ ոչ թե ընդհանուր գաղտնիք։ EAP եղանակները հասնում են նույն տեղը այլ ճանապարհով, երբ նույնականացման սերվերը բանալիները վերադարձնում է որպես MS-MPPE-Recv-Key և MS-MPPE-Send-Key հատկանիշներ։ Սովորական CHAP-ը չի հայտնվում ճանապարհներից ոչ մեկում, և դա է անհամապատասխանության գոյության ամբողջ պատճառը։

Կազմաձևը, որը պահանջում է MPPE, բայց մերժում է բանալիներ տալու ընդունակ բոլոր եղանակները, ներքուստ հակասական է։ pppd-ն լուծում է այդ հակասությունը կապը մերժելով, ոչ թե բանալիներ հորինելով, ուստի տեսանելի արդյունքը նստաշրջան է, որը նույնականացվում է և ապա ավարտվում ցանցային փուլում։ Հաճախորդի կրկնակի փորձը դա չի փոխի, քանի դեռ սերվերը մերժում է ինչ-որ բան ածանցող միակ եղանակները։

Դրանից բխող կանոնը կարճ է՝ եթե պրոֆիլը պահանջում է MPPE, եղանակը պետք է լինի MS-CHAP-ի տարբերակ կամ EAP եղանակ, որի բանալիները սերվերը վերադարձնում է։ Միայն MS-CHAPv2-ը մերժելը դա չի պարտադրում, որովհետև MS-CHAPv1-ը նույնպես ածանցում է բանալիներ և հասանելի է մնում, եթե առանձին չմերժվի՝ երկուսն էլ մերժելը թողնում է սովորական CHAP և PAP, որոնք ոչինչ չեն ածանցում և պահանջը դարձնում են անկատարելի։ Անվանեք ընդունված եղանակը հստակորեն՝ ձեր չսիրածները թվարկելու փոխարեն։ Գաղտնագրման պահանջը թողնելը, որպեսզի հաճախորդը միանա, իջեցում է, ոչ թե վերանորոգում։

Կարդացեք սերվերի ընտրանքները նախքան հաճախորդը խմբագրելը

Այս անհամապատասխանությունների մեծ մասը սերվերի վրա տեսանելի է երկու ֆայլում, և դրանք կարդալը ավելի էժան է, քան հաճախորդը վերակառուցելը։ Linux PPTP վերջնակետում համապատասխան կարգավորումները ապրում են pppd-ի ընտրանքների ֆայլում, որը փոխանցում է pptpd-ն։ Գործարկեք այն սերվերի վրա, ոչ թե հաճախորդի կարգավիճակի էկրանից։ Սկսեք այն տողերից, որոնք պահանջում, մերժում կամ անվանում են պաշտպանության ռեժիմ:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Կարդացեք ելքը որպես պայմանագիր, ոչ թե դրոշների ցանկ։ Այն տողը, որը պահանջում է MPPE, բայց մերժում է MS-CHAP-ի երկու տարբերակները, ոչ մի հաճախորդ չի կարող բավարարել, և MS-CHAP եղանակի համար բացակայող պահանջը դուռը բաց է թողնում բանալի չտվող փոխանակումների համար։ Այնուհետև ստուգեք, թե ով իրավունք ունի ընդհանրապես նույնականանալ, ինչը որոշում է գաղտնիքների ֆայլը:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

Գտեք ձախողումը ըստ PPP փուլի

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

Օրագիրը պահում է փուլային տողերը, և դրանք ավելի օգտակար են, քան վրիպազերծման ավելի բարձր մակարդակը։ Պահանջեք PPP գործընթացները և պաշտպանության հաղորդագրությունները, ապա նույնականացման արդյունքը կարդացեք ամեն ինչից առաջ։ Վերջին տողերը սովորաբար անվանում են մերժած կետը:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

Պլանավորեք ելքը նախքան հին վերջնակետի անջատումը

MPPE-ն կապի պաշտպանության պատմական մեխանիզմ է, և դրա առկայությունը PPTP-ն խելամիտ ընտրություն չի դարձնում նոր տեղակայման համար։ Microsoft-ի ընթացիկ ուղեցույցն արդեն խորհուրդ է տալիս PPTP-ի դեմ և նախապես համօգտագործված բանալիով L2TP/IPsec-ի դեմ՝ հեռահար մուտքի նոր տեղակայումների համար։ Հին վերջնակետը կենդանի պահելը որոշում է գոյություն ունեցող ծառայության մասին, ոչ թե ձևանմուշ հաջորդի համար։

Երբ վերջնակետը պետք է մնա, գրեք պայմանագիրը: արտաքին արձանագրությունը, պահանջվող նույնականացման եղանակը, պարտադիր պաշտպանությունը և այն հաճախորդի տարբերակը, որը բանակցում է այն։ Երբ այն կարող է գնալ, ընտրեք փոխարինողի դարպասի ինքնությունը, նրա հաճախորդի նույնականացումը և այն վայրը, որտեղ կապրեն հավատարմագրերը, նախքան հին պրոֆիլին դիպչելը։ Այնուհետև պլանավորեք երթուղիները, DNS-ը և այն ռեսուրսները, որոնց յուրաքանչյուր օգտատեր իրավասու է հասնել։ Ստուգեք նախատեսված հաճախորդին ըստ սեփականատիրոջ պահանջների, այլ ոչ թե ըստ աշխատող կապի։

Կանխամտածված մերժումը պետք է մերժում մնա, որովհետև թեստը անցնելու համար անպաշտպան ռեժիմի անկումը քաղաքականության ձախողումը վերածում է բացահայտման։ Ավարտված վիճակը աջակցվող, փաստաթղթավորված պայմանագիր է, ոչ թե փոփոխությունների ամենափոքր հավաքածուն, որը հաջողեցնում է մեկ հին կապ։ Թողեք հին պրոֆիլը տեղում՝ չօգտագործված և փաստաթղթավորված, մինչև փոխարինողը անցնի նույն ստուգումները։