LXD-ի կոնտեյները չի բացում /dev/net/tun-ը։ Ստուգեք unix-char գրառումը
LXD-ը պետք է հոսթի TUN սարքը փոխանցի կոնտեյներին, նախքան VPN հաճախորդը կկարողանա այն օգտագործել։ Տեսեք, թե ինչ է ավելացնում unix-char-ը, ինչը՝ ոչ, և ինչպես ստուգել այն։
LXD-ը հոսթի նշանային սարքը կոնտեյներին ներկայացնում է սարքային հանգույց ավելացնելով, ոչ թե հյուրին սովորեցնելով ստեղծել այն։ Եթե կոնտեյներում /dev/net/tun չկա, սարքը կարող է լինել հոսթում, և հյուրը միևնույն է չի կարողանա բացել այն։ unix-char գրառումը այդ ուղու կառավարչի կողմի կեսն է, և այն դիտավորյալ ավելի նեղ է, քան արտոնյալ կոնտեյները։ Այդ պատճառով հոսթի հանգույցը և կոնտեյների հանգույցը արժանի են առանձին ստուգումների։
Մեխանիզմը բավական կարճ է, որպեսզի մնա տեսադաշտում․ LXD-ը լուծում է հոսթի ուղին, ստեղծում է համապատասխան հանգույց օրինակի ներսում և սարքը ավելացնում է կոնտեյների սարքերի cgroup-ին։ Դրանից հետո հյուրի պրոցեսին անհրաժեշտ են իր սեփական թույլտվությունը և կարողությունը՝ հանգույցն ինչ-որ բանի համար օգտագործելու համար։
Ինչ է իրականում փոխում unix-char գրառումը
unix-char սարքը LXD-ին ասում է հոսթի մեկ նշանային սարքը ներկայացնել կոնտեյների ներսում ընտրված ուղու վրա։ Գրառումն ունի երեք կարևոր մաս՝ կառավարչի օգտագործած սարքի պիտակը, հոսթի source ուղին և այն path-ը, որը տեսնում է հյուրը։ Միայն վերջին երկուսն են նկարագրում սարքն ինքը։ Դրանցից որևէ մեկում տպագրական սխալը ստեղծում է հանգույց մի տեղում, որը հաճախորդը երբեք չի բացում։
Հոսթում սարքը սովորաբար /dev/net/tun է։ Կոնտեյների ներսում կարող եք պահել նույն ուղին կամ ընտրել մեկ ուրիշը, բայց ուղին պետք է համապատասխանի այն բանին, ինչ սպասում է VPN հաճախորդը։ /dev/net/tun-ը պահելը խուսափում է երկրորդ կարգաբերման խնդրից, քանի որ հաճախորդների մեծ մասը բացում է այդ ուղին առանց հարցնելու։
Կառավարիչը գրառումը կիրառում է օրինակի մեկնարկի կամ սարքի տաք միացման պահին։ Այն չի պատճենում վարորդ հյուրի մեջ և չի ստեղծում թունելի ինտերֆեյս։ Այն հանգույցը դարձնում է տեսանելի և թույլատրում է հասանելիություն կոնտեյների սարքերի կառավարման խմբի միջոցով։
Հայտարարեք սարքը օրինակի վրա, ոչ թե հյուրի ներսում
Ավելացրեք գրառումը LXD-ի կառավարման համատեքստից՝ նշելով օրինակը և պիտակ, որը հետագայում կճանաչեք։ vpnbox անունով կոնտեյների համար հրամանը սա է․
lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox
tun պիտակը տեղական է օրինակի կարգաբերմանը։ Այն ինտերֆեյսի անուն չէ և պարտավոր չէ որևէ բանի համապատասխանել հյուրում։ Եթե պրոֆիլն արդեն տալիս է նույն սարքը, երկրորդ գրառումը ավելացնելը ստեղծում է հակամարտություն, ոչ թե ավելորդություն, ուստի նախ ստուգեք գործող կարգաբերումը։
Կոնտեյների ներսում ֆայլերը խմբագրելը սխալ շերտ է։ Մեկնարկային սկրիպտում mknod-ը կարող է թվալ, թե աշխատում է արտոնյալ կոնտեյներում, ապա անհետանալ վերաստեղծման ժամանակ կամ ձախողվել ավելի քիչ արտոնյալում։ Օրինակի սարքերի հավաքածուն պատկանում է կառավարչին․ թող նաև հանգույցը պատկանի նրան։
Համաձայնեցրեք սեփականությունը և ռեժիմը հյուրի պրոցեսի հետ
unix-char գրառումը կարող է սահմանել uid, gid և mode կոնտեյների ներսի հանգույցի համար։ Օգտագործեք դրանք VPN հաճախորդը գործարկող հաշվին համապատասխանելու համար, փոխարենը սարքը բոլոր օգտատերերի համար բացելու կամ կոնտեյները արտոնյալ ռեժիմի անցնելու։
Տեսանելիությունը նույնը չէ, ինչ թույլտվությունը։ root-ին պատկանող և 600 ռեժիմով հանգույցը տեսանելի է ոչ արտոնյալ օգտատիրոջով աշխատող ծառայությանը և այնուամենայնիվ նրա կողմից չի բացվում։ Նախ ստուգեք հյուրի հաշիվը, ապա սեփականությունը հանձնեք այդ հաշվին և ռեժիմը չպահեք ավելի լայն, քան հաճախորդին անհրաժեշտ է։
Պրոցեսին անհրաժեշտ է նաև թունելի ինտերֆեյս կարգաբերելու կարողությունը, սովորաբար CAP_NET_ADMIN կոնտեյների ցանցային անվանատարածքում։ Սարքը փոխանցելը չի տալիս այդ կարողությունը, և կարողությունը տալը չի ապահովում սարքը․ դրանք անկախ պահանջներ են։
Իմացեք, թե ինչ չի տալիս գրառումը
Տեսանելի հանգույցը աշխատող VPN չէ։ Հաճախորդի փաթեթը դեռ պետք է տեղադրվի, պրոֆիլը դեռ պետք է վավեր լինի, և ծառայությունը դեռ պետք է մեկնարկի։ Նույնականացումը, երթուղիները և DNS-ը մնում են հաճախորդի գործը, և այնտեղի ձախողումը ապացույց չէ, որ սարքի գրառումը սխալ է։
systemd-ը կարող է ևս մեկ սահմանափակում ավելացնել։ DeviceAllow կամ կարծրացված սարքային քաղաքականություն ունեցող միավորը կարող է մերժել հասանելիությունը կոնտեյների կառավարչի տրամադրած հանգույցին։ Երբ հանգույցը կա, բայց ծառայությունը հայտնում է թույլտվության սխալ, ստուգեք միավորի սարքային քաղաքականությունը և փոխեք այն քաղաքականությունը՝ կոնտեյները լայնացնելու փոխարեն։
Տաք միացումը ընտրովի է և բացահայտ։ required=false ունեցող գրառումը պահանջում է աղբյուրի ուղի և կարող է հայտնվել կամ անհետանալ, երբ հոսթի սարքը փոխվում է։ Այդ կենսացիկլը հարմար է եկող-գնացող սարքավորմանը․ VPN-ին մեկնարկին անհրաժեշտ TUN սարքի համար ընտրովի գրառումը կարող է թույլ տալ ծառայությանը մեկնարկել նախքան դրա նախապայմանի գոյությունը։
Ստուգեք տեսանելիությունը, բացումը և ինտերֆեյսը հենց այդ հերթականությամբ
Նախ հաստատեք հանգույցը նախատեսված կոնտեյների ներսում։ Ուղին, հիմնական և երկրորդական համարները և սեփականությունը պետք է համապատասխանեն հոսթի սարքին և ձեր ավելացրած գրառմանը։ Բացակայող հանգույցը նշանակում է, որ կառավարիչը գրառումը չի կիրառել կամ կիրառել է այլ օրինակի վրա։
lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'
Ապա հաստատեք, որ ծառայության հաշիվը կարող է բացել այն։ Այդ հաշվով կարճ փորձարկումը բաժանում է սեփականության խնդիրը ծառայության խնդրից։ Վերջում գործարկեք հաճախորդը և հաստատեք, որ թունելի ինտերֆեյս է հայտնվում․ միայն այդ երրորդ քայլն է ապացուցում ամբողջ ուղին, որովհետև առաջին երկուսը կարող են անցնել, մինչ հաճախորդի պրոֆիլը կամ կարողությունը դեռ սխալ է։
Երբ փոփոխությունը հաստատվի, գրանցեք օրինակը, սարքի պիտակը, հոսթի աղբյուրը, հյուրի ուղին և տիրոջ հաշիվը։ Այդ հինգ արժեքներն են, որ հետագա վերաստեղծումը, տեղափոխումը կամ պրոֆիլի փոփոխությունը պետք է պահպանեն, և դրանք շատ ավելի հեշտ է համեմատել, քան համատեքստից զուրկ թույլտվության սխալը։