L2TP առանց IPsec-ի Linux-ում՝ xl2tpd, pppd և NAT

Մերկ L2TP-ն PPP է ծրարի մեջ, և ոչ այլ բան։ Այն կրում է ձեր կադրերը, բայց չի գաղտնագրում դրանք և չի ապացուցում, թե ով է նստած մյուս ծայրում, դրա համար էլ գրեթե ամեն տեղակայում IPsec է մտցնում դրա տակ։ Մերկ տարբերակը գործարկելու ազնիվ պատճառներ դեռ կան՝ լաբորատոր սեղան, միգրացիայի քայլ կամ միացում, որն արդեն իսկ գտնվում է մեկ այլ պաշտպանված ուղու մեջ։

Եթե այնուամենայնիվ առաջ եք գնում, գրեք այդ զգուշացումը նախագծի նշումում և թողեք այնտեղ։ Այն, ինչ հաջորդում է, այն գործառնական ուղին է, որն օգտագործում եմ Debian-ի և RHEL-ի ընտանիքի հոսթերում՝ որ ֆայլն ինչի համար է պատասխանատու, MTU-ն, որը կանխում է դասական խցանումը, և վերահասցեավորման կանոնները, որոնք թունելը դարձնում են արժեքավոր։

Երեք ֆայլ բաժանում են աշխատանքը

xl2tpd-ն ավարտում է կառավարման կապը և յուրաքանչյուր սեսիա փոխանցում է PPP դեմոնին, ուստի կոնֆիգուրացիան բաշխված է երկու ծրագրերի միջև, որոնք երբեք չեն կարդում միմյանց ֆայլերը։ Լսողը գտնվում է /etc/xl2tpd/xl2tpd.conf-ում՝ [lns default] բաժնի ներսում, որը հասցեների լողավազանը նշում է ip range-ով, սերվերի կողմը՝ local ip-ով, իսկ PPP-ին հանձնումը՝ pppoptfile-ով։ Միացրեք require authentication = yes-ը, թողեք length bit-ը և flow bit-ը միացված, և ընտրեք լողավազան, որն այլևս ոչինչ չի օգտագործում հոսթում։

PPP քաղաքականությունը պատկանում է այն ֆայլին, որը նշում է այդ ընտրանքը, սովորաբար /etc/ppp/options.xl2tpd-ին՝ auth, pap-ի, chap-ի և mschap-ի մերժումներ, require-mschap-v2, 1460-ի MTU և MRU, և DNS հասցե, որին հաճախորդը կարող է հասնել կապը բարձրանալուց հետո։ Հավատարմագրերն էլի երրորդ ֆայլն են՝ /etc/ppp/chap-secrets-ը, որտեղ երկրորդ դաշտը պետք է համապատասխանի LNS բաժնի անվանը, իսկ չորրորդը կարող է ամրացնել լողավազանից կոնկրետ հասցե։

Ինչու է թունելը միանում, ապա կախվում

1500 բայթանոց Ethernet կադրը չի տեղավորվում ուղու մեջ, որն արդեն բայթեր է ծախսում իր սեփական վերնագրերի վրա։ Արտաքին IPv4 վերնագիրը արժե 20, UDP-ն՝ 8, իսկ L2TP վերնագիրը՝ մոտ 12, ինչը 1460 է թողնում PPP-ին և նրա բեռնվածքին։ Հենց այդ ավելի փոքր թվի հայտարարումն է PPP-ում, որ թույլ չի տալիս մեծ փաթեթներին մասնատվել կամ լուռ կորչել ինչ-որ տեղ մեջտեղում։

Ախտանիշը թունել է, որը առողջ է թվում մինչև իրական երթևեկության գալը՝ ping-ները և կառավարման հաղորդագրությունները անցնում են, ֆայլի պատճենումը կախվում է, և ոչինչ մատյանում չի բացատրում դա։ Իջեցրեք MTU-ն և MRU-ն միասին երկու ծայրերում։ Միայն հաճախորդի կարգավորումը սովորաբար կոշտ խցանումը դարձնում է պարբերական, ինչն ավելի վատ է ախտորոշելու համար։

Մեկ պորտ երկու զրույց է տանում

UDP 1701-ը գտնվում է արձանագրության երկու կեսերի տակ, և այդ մեկ փաստը ավելի շատ հրետանային կանոններ է կոտրում, քան տեղադրման ցանկացած այլ մաս։ Սկզբում գալիս են կառավարման կապի մեկնարկի հարցումը և դրա պատասխանը, ապա հաջորդող սեսիայի հարցումն ու հաստատումը ոչինչ ավելին չեն հաստատում, քան նույնացուցիչների զույգը։ Դրանից հետո PPP-ն ստանձնում է՝ կապի կառավարում, ապա նույնականացում, ապա IP կառավարման արձանագրություն՝ հասցեները համաձայնեցնելու համար։ Յուրաքանչյուր փուլ ունի իր բառապաշարը մատյանում, և դրանցից ոչ մեկը իրեն չի հայտարարում որպես L2TP ձախողում։

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

Թունելը դարձնել օգտակար՝ վերահասցեավորում և NAT

Սեսիան ինքնին հասնում է միայն սերվերին։ Հաճախորդի ինտերնետ հասանելիությանը պետք են վերահասցեավորում, լողավազանի համար NAT կանոն վերին կապում և DNS, որին հաճախորդը կապը բարձրանալուց հետո իսկապես կարող է հարցում ուղարկել։ Լողավազանը նույնպես պետք է հեռու մնա LAN տիրույթից, այլապես հաճախորդներին ուղղված պատասխանները մատուցվում են տեղում՝ թունել վերադարձնելու փոխարեն։

Սերվերի վրա միացրեք վերահասցեավորումը sysctl -w net.ipv4.ip_forward=1-ով, թարգմանեք լողավազանը iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE-ով, ապա ընդունեք ելքային թունելային երթևեկությունը FORWARD կանոնով -i ppp0 -o eth0-ի համար, իսկ վերադարձողը՝ հայելային կանոնով և -m state --state RELATED,ESTABLISHED-ով։ Պահպանեք այդ կանոնները վերագործարկումների միջև, որովհետև առանց դրանց վերադարձող սերվերը ճիշտ կոտրված L2TP կոնֆիգուրացիայի տեսք ունի։

Սերվերի սեփական LAN-ին հասնելը այլ խնդիր է՝ ավելացրեք վերադարձի երթուղի լողավազանի համար LAN երթուղղորդիչի վրա, կամ proxy ARP սերվերի վրա։ Հաճախորդներին NAT-ի հետևում թաքցնելը, երբ LAN-ի ներսում ինչ-որ բան պետք է ուղղակիորեն դիմի նրանց, ընդամենը հետագայի համար երկրորդ վրիպազերծման սեսիա է պլանավորում։

Ինչ չի անում մերկ կույտը, և ինչպես ստուգել

Այս կույտի ոչ մի մաս չի գաղտնագրում PPP կադրերը, և դրանում ոչինչ չի նույնականացնում հեռավոր ծայրը որպես այն սերվեր, որը դուք իրոք ընտրել եք։ MS-CHAPv2-ը իսկապես պաշտպանում է հավատարմագրերի փոխանակումը միայն դիտող ունկնդրից, սակայն ուղու վրա տեղադրված հարձակվողը դեռ կարող է միջամտել սեսիային։ Windows-ի բնիկ հաճախորդը L2TP-ն առաջարկում է միայն IPsec-ի հետ համատեղ, ուստի հաշվի առեք Linux-ը, երթուղղորդիչների որոնվածը և երրորդ կողմի հաճախորդները որպես ձեր գործընկերներ։ Վերաբերվեք մերկ կոնֆիգուրացիային որպես ախտորոշիչ աստիճան, երբեք որպես կանգ առնելու տեղ։

Ստուգեք ֆիքսված հերթականությամբ՝ գործարկեք xl2tpd -D-ն առաջին պլանում, հետևեք մատյանին PPP փուլի համար, կարդացեք տրված հասցեն ip addr-ից երկու ծայրերում, ապա գրավեք UDP 1701-ը՝ հաստատելու, որ տվյալները հոսում են սեսիան բարձրանալուց հետո։ Եթե բոլոր չորսը համընկնում են, և երթևեկությունը դեռ ձախողվում է, մեղքը երթուղավորման, NAT-ի կամ MTU-ի մեջ է, ոչ թե հենց L2TP-ի։