NET_ADMIN-ը VPN կոնտեյներում՝ ինչ և որտեղ կարող է փոխել

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

Ինչ է ընդգրկում հնարավորությունը

Իր անվանատարածքի ներսում NET_ADMIN ունեցող գործընթացը կարող է բարձրացնել և իջեցնել ինտերֆեյսները, նշանակել հասցեներ, ավելացնել և հեռացնել երթուղիներ և գրել firewall-ի կանոններ, ինչը այն գործողությունների խումբն է, որը capabilities(7)-ը հավաքում է այս հնարավորության ներքո։ Այն կարող է նաև կարգավորել ինտերֆեյսի մակարդակի պարամետրեր, որոնք վերահսկում են, թե ինչպես է միջուկը հերթագրում և զտում երթևեկությունը։ VPN հաճախորդին սովորաբար անհրաժեշտ են դրանցից մի քանիսը մեկնարկի ժամանակ և ոչինչ՝ դրանից հետո։ Այդ պատճառով պատկերների մեծ մասը պահանջում է ավելի մեծ հասանելիություն, քան օգտագործում է։

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

Անվանատարածքը որոշում է վնասի շառավիղը

Սեփական կամուրջ-ցանցում գտնվող կոնտեյները հասնում է իր loopback-ին, իր ինտերֆեյսներին և իր երթուղային աղյուսակին։ Այնտեղ NET_ADMIN տալը թույլ է տալիս VPN հաճախորդին թունել կառուցել՝ չհպվելով հոսթի երթուղային որոշումներին, ինչը այն դասավորությունն է, որը ենթադրում են կոնտեյներային պատկերների մեծ մասը։

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

Երեք նախապայման, որ միաձուլվում են մեկի մեջ

VPN կոնտեյներների մեկնարկային խափանումները սովորաբար վերաբերում են երեք առանձին բաներից մեկին՝ հնարավորությանը, թունելի սարքին և միջուկի աջակցությանը արձանագրությանը։ Բոլոր երեքը միաժամանակ տալը աշխատում է, և դա նաև անհնար է դարձնում հաջորդ խափանումը վերագրելը։ Նվազագույն compose հատվածը տալիս է հնարավորությունը և բացահայտ փոխանցում սարքի հանգույցը.

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

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

Տվեք նեղ գործողությունը, ոչ թե ռեժիմը

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

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

Գաղտնիքները առանձին որոշման առարկա են։ NET_ADMIN ունենալը ոչինչ չի ասում այն մասին, թե ինչ զուգընկերոջ ինքնություն է ներկայացնում հաճախորդը, ինչ հավատարմագրեր է բեռնում կամ ինչպես են դրանք պտտվում։ Ցանցային կառավարումը վստահություն չի տալիս։

Ստուգեք փոփոխությունը և գրանցեք, թե ինչու է թույլտվությունը գոյություն ունի

Նախքան թունելի վրիպազերծումը հաստատեք, թե ինչ է իրականում ստացել կոնտեյները։ Ստորև զննումը հաղորդում է ավելացված հնարավորությունները և ցանցային ռեժիմը, ապա ցույց է տալիս, թե ինչպիսին է ինտերֆեյսների ցանկը ներսից.

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

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

Փորձարկեք նաև ապամոնտաժման ուղին, քանի որ firewall-ի կանոններ գրող հաճախորդը կարող է դրանք հետևում թողնել։ Կանգնեցրեք կոնտեյները և նորից ստուգեք հոսթի կանոնների հավաքածուն, եթե օգտագործվում է հոսթային ցանց։ Թույլտվությունը, որն անհրաժեշտ է մեկնարկին ընդամենը երկու վայրկյան, չպետք է compose ֆայլում նկարագրվի որպես մշտական պահանջ՝ առանց դա բացատրող նշումի։

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