PPTP-ը Docker-ում նույնականացվում է, բայց տրաֆիկ չի տեղափոխում

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

Հինգ ստուգում՝ այն հերթականությամբ, որն ամենաշատ ժամանակն է խնայում։

Ստուգում 1. առանձնացրեք կառավարման ալիքը բեռից

PPTP-ն նույնականացվում է TCP 1723-ի վրայով և հետո PPP բեռը տեղափոխում է GRE-ի ներսում՝ IP 47 արձանագրություն։ GRE-ն ոչ TCP է, ոչ UDP, ուստի կառավարման պորտը փոխանցող յուրաքանչյուր կանոն դրա մասին ոչինչ չի ասում։ 1723-ը թողնող NAT-ը կամ հրապատը կարող է առանց բողոքի գցել 47 արձանագրությունը, և սեանսը մնում է կիսակառույց այնպես, որ հաջողություն է թվում։

Եթե մուտքը աշխատում է, և ոչ մի փաթեթ չի վերադառնում, նախ ենթադրեք GRE, ապա դա ապացուցեք։

Ստուգում 2. հաստատեք օգնականը հոսթի միջուկում

Կապերի հետևումը չի կարող առանց օգնականի կապել TCP կառավարման կապը GRE հոսքին։ Մոդուլը nf_conntrack_pptp-ն է, այն ապրում է հոսթի միջուկում, և կոնտեյների պատկերի ներսում այն բեռնելը ոչինչ չի տալիս, քանի որ մոդուլները գործում են ամբողջ հոսթում։ lsmod | grep nf_conntrack_pptp-ը Docker հոսթում հենց ստուգումն է։ Եթե այն բացակայում է, modprobe nf_conntrack_pptp-ը բեռնում է այն ընթացիկ միջուկի համար և ոչինչ չի ասում հաջորդ բեռնարկման մասին, ուստի ավելացրեք այն նաև հոսթի կարգավորումներում։

Վերագործարկման ժամանակ անհետացող մոդուլը հաջորդ ամիս դառնում է նույն տոմսը։

Ստուգում 3. կարդացեք միջուկի քաղաքականությունը, որն անջատում է այն

Նույնիսկ մոդուլի առկայության դեպքում 4.7-ից ի վեր միջուկները net.netfilter.nf_conntrack_helper-ը լռելյայն դնում են 0, ինչը անջատում է ավտոմատ օգնականի նշանակումը բոլոր արձանագրությունների համար։ Այդ լռելյայնն է պատճառը, որ ճիշտ տեղադրված մոդուլը դեռ ոչինչ չի անում՝ կոդը կա, իսկ քաղաքականությունն ասում է՝ չօգտագործել։ sysctl net.netfilter.nf_conntrack_helper-ը հաղորդում է ընթացիկ արժեքը, և այն գործարկման ժամանակ 1-ի դնելը օգնականին կրկին հասանելի է դարձնում։ Պահպանեք արժեքը հոսթի sysctl կարգավորման միջոցով, եթե նախագիծը թույլ է տալիս։

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

Ստուգում 4. առանձին նայեք կոնտեյների ուղուն

Բեռնված օգնականը երթուղի չի ստեղծում։ Կոնտեյներին պետք է ուղի դեպի PPTP սերվեր, և հոսթի փոխանցումը պետք է թույլ տա GRE երկու ուղղություններով՝ iptables -L FORWARD -v -n-ը ցույց է տալիս՝ արդյոք 47 արձանագրությունն ընդունվում է, և արդյոք հաշվիչները շարժվում են։ Docker-ի masquerade կանոնները թարգմանում են TCP-ն և UDP-ն, ոչ 47 արձանագրությունը, ուստի կամուրջով կոնտեյներին կարող է պետք լինել հստակ forward թույլտվություն և որոշ հոսթերում՝ սեփական թարգմանության կանոն։ Համոզվեք նաև, որ կոնտեյներն ունի իր պատկերի ակնկալած PPP սարքի աջակցությունը։

Կարդացեք հաշվիչները, ոչ թե կանոնի տեքստը։ Կանոնը, որը գոյություն ունի և ոչնչի չի համապատասխանում, զարդարանք է։

Ստուգում 5. ապացուցեք, որ GRE-ն հետևվում է, ապա որոշեք PPTP-ի մասին

Երբ հաճախորդը աշխատում է, կարդացեք հետևման աղյուսակը։ Հաստատված PPTP կառավարման գրառումը գումարած հարակից GRE գրառումը նշանակում է, որ օգնականը կապում է հոսքերը, և մնացած խափանումը այլ տեղ է։ Կառավարման գրառումն առանց GRE գրառման նշանակում է, որ բեռը գցվում է կամ չի հետևվում, ինչը ձեզ վերադարձնում է 2 և 3 ստուգումներին։

PPTP-ն ինքնին հնացած է, և MS-CHAPv2-ը թույլ է։ Եթե սերվերն առաջարկում է նաև L2TP/IPsec, IKEv2 կամ WireGuard, ապա դրանցից մեկին անցնելը հեռացնում է խնդիրների այս ամբողջ դասը։

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