PPTP-ում LCP-ն ընդհատել է գործընկերը. նախ միացրեք MPPE-ն

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

Ինչ է ասում LCP-ի ձախողումը PPP փուլի մասին

PPTP-ն PPP-ն փաթաթում է GRE-ի մեջ. TCP 1723 կառավարման միացումը կարգավորում է զանգը, GRE-ն կրում է բեռը, ապա LCP-ն բանակցում է այնպիսի ընտրանքների շուրջ, ինչպիսիք են նույնականացման արձանագրությունը, սեղմումը և MPPE-ն։ Գործընկերը դադարեցնում է LCP-ն, երբ պարտադիր ընտրանքն իր կողմում անընդունելի է։ Մատյանը, որտեղ CHAP-ի կամ MSCHAPv2-ի փոխանակումն ավարտվում է, և LCP-ն անմիջապես դրանից հետո ավարտվում է, քաղաքականության մերժում է, ոչ թե հասանելիության ձախողում։ Եթե թունելը բանակցության ընդհանրապես չի հասնում, ստուգեք pppd-ն և դրա plugin-ը՝ նախքան LCP տողը կարդալը։

Երկու նախապայման հեշտ է բաց թողնել։ pppd-ի բինար ֆայլը պետք է գոյություն ունենա, և գործընկեր ֆայլում նշված PPTP plugin-ը պետք է տեղադրված լինի. բացակայող փաթեթը ավարտում է զանգը ցանկացած ընտրանքի քննարկումից առաջ։

Միացրեք MPPE-ն այն կողմում, որը պահանջում է այն

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

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Զանգից առաջ բեռնեք մոդուլը modprobe ppp_mppe-ով, որովհետև առանց դրա require-mppe-128-ը ձախողվում է։ Windows-ում համարժեք կառավարումը VPN գրառման անվտանգության ներդիրն է, որտեղ հաճախորդին պետք է ասել, որ պահանջի կոդավորում՝ փոխարենը սերվերի առաջարկածն ընդունելու։ Եթե սերվերը դեռ դադարեցնում է LCP-ն, հարցրեք դրա օպերատորին՝ MPPE-ն պարտադիր է, ընտրովի, թե անջատված, քանի որ հաճախորդը չի կարող բանակցել այնպիսի պաշտպանության շուրջ, որը սերվերը մերժում է։ Կոդավորումն անջատելը, որպեսզի հաղորդագրությունը անհետանա, սխալ ուղղություն է. դա հեռացնում է միակ պաշտպանությունը, որն ունի այս արձանագրությունը։

Պահպանեք աշխատող գործընկեր ֆայլը՝ նախքան այն խմբագրելը։ Սխալ մուտքագրված require-mppe տողը վերարտադրում է նույն ընդհանուր LCP ձախողումը և ձեզ հետ է ուղարկում սկիզբ։

Կարդացեք pppd-ի սեփական մատյանը, ոչ թե applet-ը

Սեղանի applet-ները ցույց են տալիս անջատումը և թաքցնում պատճառը, ուստի կարդացեք դեմոնի պատումը մեկ փորձի մասին։ systemd համակարգերում հաղորդագրությունը հայտնվում է journal-ում. ավելի հին կարգավորումները գրում են ավանդական մատյան ֆայլերում։

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

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

Պահպանեք ուղումը վերամիացումների ընթացքում. hook անուններ և MTU

Հենց կապը կանգնում է, երկու մանրուք են որոշում՝ այն կդիմանա՞ վերամիացմանը։ Hook-երը ապրում են /etc/ppp/ip-up.d-ում և /etc/network/if-up.d-ում, և երկու պանակներն էլ մշակվում են run-parts-ով, որի ֆայլանվան զտիչը մերժում է ամեն ինչ, ինչ պարունակում է կետ։ Այդ պատճառով set-pptp.sh անունով script-ը բաց է թողնվում, մինչդեռ set-pptp-ը կատարվում է։ Ստուգեք անունը՝ նախքան script-ի բովանդակությունը վրիպազերծելը, ապա սահմանեք ավելի փոքր MTU-ն հենց այդ hook-ի ներսից, որպեսզի յուրաքանչյուր նոր ppp միջերես ժառանգի այն առանց ձեռքով հրամանի։

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Նստաշրջանը դիտավորյալ ավարտելու համար նպատակադրեք pppd-ի գրանցած pid-ը՝ փոխարենը գործընթացների անունները օրինակով համապատասխանեցնելու, որովհետև ppp պարունակող ամեն ինչ սպանելը քանդում է նաև անկապ կապերը։ PPTP-ն հնացած է, իսկ MS-CHAPv2-ը՝ թույլ, ուստի այս ստուգումները դիտարկեք որպես աշխատող մնալու կապի սպասարկում, ոչ թե որպես PPTP-ն նոր տեղերում տեղակայելու պատճառ։