Սովորական Linux հավելվածը օգտվում է VPN-ից՝ չհպվելով TUN-ին

Հաստատված Linux VPN օգտագործող դիտարկիչը չի բացում /dev/net/tun։ Այն բացում է սոքեթ, և միջուկը որոշում է, թե որ ինտերֆեյսով են դուրս գալիս այդ սոքեթի փաթեթները։ Թունելը ստեղծած գործընթացը այլ աշխատանք է կատարում, քան այն գործընթացը, ում երթևեկությունը նա տեղափոխում է։ Այդ երկու դերերն առանձին պահելը պատասխանում է թույլտվության հարցերի մեծ մասին՝ մինչ դրանք կտրվեն։

Հետևեք մեկ փաթեթի սոքեթից մինչև թունել

Սովորական հավելվածը կանչում է connect կամ send, և միջուկը երթուղի է փնտրում նպատակակետի համար։ Եթե ընտրված երթուղին ուղղված է թունելի ինտերֆեյսին, փաթեթը հերթագրվում է այն սարքում, որը կարդում է VPN դեմոնը։ Դեմոնը գաղտնագրում է այն և ուղարկում է ֆիզիկական ինտերֆեյսով։ Այդ նկարագրության յուրաքանչյուր սլաք տեղ է, որտեղ կարելի է պատասխանել թույլտվության հարցին։

Այդ ուղու վրա ոչինչ չի պահանջում, որ հավելվածը իմանա սարքի մասին։ Դեմոնը պահում է ֆայլի նկարագրիչը և կատարում ինտերֆեյսի գործողությունները, մինչ հավելվածը տեսնում է միայն սովորական ցանցային API։

Մեկ անգամ նկարեք երկու կեսերը, և թույլտվության հարցերն ավելի հեշտ կտեղադրվեն։ Վերին կեսը հավելվածների աշխարհն է, իսկ ստորինը պատկանում է դեմոնին։

Որոշեք, թե ով է սարքի կարիքը զգում և ով՝ ոչ

TUN ինտերֆեյս ստեղծելը կամ դրան միանալը պահանջում է սարքի հասանելիություն և դրանից բացի այն կարգավորելու ունակություն, ինչի պատճառով աջակցվող VPN ծառայությունը սկսվում է ցանցի կառավարման լիազորությամբ կամ օգտագործում է արտոնյալ օգնական։ Այդ պահանջը դեմոնինն է։ Այն ոչինչ չի ասում դիտարկիչի, տվյալների բազայի հաճախորդի կամ ֆայլերի փոխանցման գործիքի մասին։ Ծառայությունը, որին ունակությունը պետք է, այն պետք է իր կարգավորման քայլի համար, ոչ իր հաճախորդների համար։

Երբ երթուղին և քաղաքականությունը տեղում են, սովորական գործընթացը օգտագործում է ստացված ուղին իր սովորական սոքեթ կանչերով։ Նրան պետք չէ սարքի հանգույցը, և պետք չէ root։

Սարքի թույլտվությունների փոփոխությունը հավելվածին նպատակակետ հասանելիություն տալու միջոց չէ։ Այն միայն սարքի սահմանը տեղափոխում է այլ տեղ։

Ստուգեք, թե իրականում որ անվանատարածքում է աշխատում հավելվածը

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

Ստուգեք ip netns list և ip -n NAME route հրամաններով, կամ դիտելով գործընթացի անվանատարածքի հղումը։ Պատասխանը սովորաբար երևում է մեկ հրամանով։

Նույն հոսթի երկու օգտատերերի կարելի է քաղաքականությամբ տարբեր ուղիներ տալ։ Դա ցանցային որոշում է, ոչ թե սարքի սեփականության ապացույց։

Առանձնացրեք ունակությունները ցանցային քաղաքականությունից

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

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

Անվանեք գործողությունը նախքան արտոնությունը անվանելը։ Երկուսը սովորաբար ավելի հեշտ է առանձնացնել, քան թվում է։

Ստուգեք բաժանումը երկու հաշիվներով

Միացրեք թունելը որպես ծառայություն, ապա գործարկեք հավելվածը որպես սովորական օգտատեր և հաստատեք, որ այն հասնում է մասնավոր ռեսուրսին։ Ստուգեք ip route get հրամանը նպատակակետի համար այդ օգտատիրոջ shell-ից՝ տեսնելու, թե որ ինտերֆեյսն ընտրվեց։ Եթե երթուղին ճիշտ է, և կապը դեռ ձախողվում է, խնդիրը քաղաքականությունն է, ոչ արտոնությունը։

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