PPTP-ն միանում է, ապա կախվում Linux NAT-ի հետևում՝ GRE օգնականը

Ինչ-որ մեկը փոխանցում է 1723-ը, հաճախորդը հասնում է սերվերին, սկսվում է նույնականացումը, և հետո ամեն ինչ կանգ է առնում առանց սխալի։ Բնական եզրակացությունը սխալ գաղտնաբառն է, ուստի գաղտնաբառը երեք անգամ նորից մուտքագրվում է։ Փոխանցումը նորմալ էր, և հավատարմագրերը նորմալ էին։ Կոտրվածը երկրորդ արձանագրությունն է, որը փոխանցումը երբեք չէր ընդգրկել, և միջուկի կանխադրված արժեք, որը հանգիստ դադարեց օգնել դրանում։

Փոխանցումը երբեք խնդիրը չէր

Պորտի փոխանցման կանոնը նկարագրում է TCP կամ UDP երթևեկությունը։ Այն չի կարող նկարագրել բեռ, որը նստաշրջանի կեսին անցնում է այլ IP արձանագրության, և PPTP-ն հենց դա է անում։

Դրա համար էլ կապը առողջ է թվում մինչև կախվելու պահը։ Այն մասը, որը պորտի կանոնը կարող է կառավարել, հաջողվեց, և այն մասը, որը չի կարող կառավարել, հենց ձախողված մասն է։

TCP՝ կառավարման, GRE՝ տվյալների համար

Զանգը բանակցվում է TCP 1723-ով։ Երբ այն կանգնում է, բեռն անցնում է GRE-ին՝ IP 47 արձանագրությանը, որը բոլորովին չի կրում պորտի համարներ։ Պորտերի վրա հիմնված կանոնը համեմատելու ոչինչ չունի։

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

Մերկ GRE-ն առանց PPTP-ի նման վերագրում չի պահանջում, դրա համար էլ սովորական GRE թունելը կարող է աշխատել այն երթուղղիչով, որը նույն ուղու վրա ձախողվում է PPTP հաճախորդի համար։

Չորս մոդուլ և sysctl, որը անջատեց դրանք

Երկու մոդուլ զբաղվում է շրջանակավորմամբ՝ nf_conntrack_proto_gre և nf_nat_proto_gre։ Եվս երկուսը զբաղվում են զանգի նույնացուցիչով՝ nf_conntrack_pptp և nf_nat_pptp։ Վերջինի բեռնումը մյուսներին ներգրավում է կախվածությունների միջոցով, ուստի մոդուլների ցանկը պետք է ցույց տա բոլոր չորսը։

Հին հրահանգները օգտագործում են 2.6 դարաշրջանի ip_ նախածանցը։ Այդ հրամանները կարող են թվալ, թե աշխատում են, մինչդեռ ոչինչ չեն բեռնում, ուստի ստուգեք բեռնված ցանկը, ոչ թե ելքի կարգավիճակը։

Դրանք բեռնված ունենալը այլևս բավարար չէ։ Linux 4.7-ից net.netfilter.nf_conntrack_helper sysctl-ը լռելյայն 0 է, ինչը անջատում է նոր հոսքերի համար օգնականի ավտոմատ նշանակումը։ Երթուղղիչը կարող է ունենալ բոլոր մոդուլները և այնուամենայնիվ ոչինչ չթարգմանել։ Ստուգեք արդյունավետ արժեքը, նախքան նորից մոդուլների ցանկին նայելը։

Կա՛մ գլոբալ կերպով նորից միացրեք ավտոմատ նշանակումը, կա՛մ օգնականը կցեք այն հոսքերին, որոնց այն պետք է, և մնացածը թողեք հանգիստ՝

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

Երկրորդ տարբերակն է նախընտրելին։ Այն վարքը սահմանափակում է PPTP երթևեկությամբ՝ ամբողջ երթուղղիչում ավտոմատ նշանակումը նորից միացնելու փոխարեն։

Բացել արձանագրություն, որը պորտեր չունի

1723-ը թույլատրող firewall-ի կանոնը ոչինչ չի ասում 47 արձանագրության մասին։ firewalld-ում թույլատրեք արձանագրությունը հաճախորդին նայող զոնայում։ Սովորական iptables-ում ընդունեք gre արձանագրությունը մուտքային շղթայում։

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

Միանալուց հետո՝ չափի սահմանը

GRE-ն ավելացնում է վերնագիր, և դրա ներսում PPP-ն ավելացնում է ավելին, ուստի աշխատող կապը հայտնում է 1500-ից զգալիորեն ցածր MTU։ Փոքր պատասխանները բեռնվում են, իսկ մեծերը կանգ են առնում, ինչը նման է երկրորդ՝ անկապ խնդրի, որը հայտնվում է առաջինի լուծման պահին։

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

Ուղու վերանորոգումը օգտատիրոջը վերադարձնում է աշխատանքի, և դա PPTP-ն լավ ընտրություն չի դարձնում։ MS-CHAPv2-ը և RC4-ը վաղուց հնացած են, ուստի մոդուլների բեռնումը դիտեք որպես ժամանակավոր ուղղում և պլանավորեք անցում պահվող արձանագրությանը։