OpenVPN-ը Docker-ում. գործարկման պայմանագիրը, որ պետք է նվազագույն հաճախորդին

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

Սկսեք արտեֆակտից, որը ինչ-որ մեկն արդեն հաստատել է։ Ստորև բերված քայլերը ենթադրում են պատկեր, որը պարունակում է openvpn կատարվող ֆայլը և ամբողջական հաճախորդի պրոֆիլ, որի վկայագիրը և բանալու նյութը արդեն լուծված են մոնտաժի ներսում։ Դրանք ծրագրակազմ չեն կառուցում, հավատարմագրեր չեն թողարկում և չեն ընդգրկում առանց root-ի գործարկման միջավայրեր կամ Windows-ի բնիկ կոնտեյներներ, որոնցից յուրաքանչյուրը փոխում է պատասխանը։

Ինչ է ստանում կոնտեյները և ինչ՝ ոչ

Պահեք պրոֆիլը և այն ամենը, ինչին այն հղվում է, սահմանափակ թույլտվություններով տեղական թղթապանակում՝ մոնտաժված միայն-կարդալու համար։ Պրոֆիլի ներսի հարաբերական ուղիները պետք է լուծվեն այդ մոնտաժի ներսում՝ սա մանրամասն է, որը մարդիկ բաց են թողնում, երբ վկայագիրը գտնվում է պրոֆիլից մեկ թղթապանակ վերև, և կոնտեյները երբեք չի տեսնում այն։

services:
  vpn:
    image: ${VPN_CLIENT_IMAGE:?set the reviewed image reference}
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - ./vpn:/vpn:ro
    working_dir: /vpn
    entrypoint: ["openvpn"]
    command: ["--config", "/vpn/client.ovpn"]

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

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

Կարողություններ, entrypoint և նրանց միջև եղած թակարդը

Անհրաժեշտ են երկու կարգավորում, և դրանք անկապ աշխատանք են կատարում։ NET_ADMIN թույլ է տալիս փոխազդել ինտերֆեյսների և երթուղիների հետ կոնտեյների անունների տարածքում։ /dev/net/tun սարքի գրառումը թույլ է տալիս գործընթացին ընդհանրապես բացել թունելի սարքը։ Մեկը առանց մյուսի տալը ստեղծում է հստակ ձախողում, ինչը հարմար է՝ բացակայող TUN սարքը ձախողվում է բացման պահին, իսկ բացակայող կարողությունը ձախողվում է, երբ հաճախորդը փորձում է կարգավորել ինտերֆեյսը։

Դրանցից ոչ մեկը չի արդարացնում privileged: true-ը։ Արտոնյալ կոնտեյնը ստանում է բոլոր կարողությունները գումարած սարքերի հասանելիությունը, և դա շատ ավելի մեծ տրամադրում է, քան այս աշխատանքային բեռին անհրաժեշտ է։ գործարկման միջավայրի արտոնությունների և կարողությունների հղումը բացատրում է, թե որքան հեռու է հասնում այդ տրամադրումը։ Եթե chart-ը կամ բլոգի գրառումը պահանջում է դա, նախ ստուգեք, թե արդյոք պահանջը իրականում բացակայող սարքի ուղի էր, թե բացակայող կարողություն։

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

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

Ստուգեք անունների տարածության ներսից, ոչ թե հոսթից

Բարձրացրեք stack-ը, մատյանում հաստատեք, որ հաճախորդը հասել է միացված վիճակի, ապա ստուգեք այն անունների տարածությունը, որն իսկապես պահում է թունելը։

docker compose up -d
docker compose logs --tail 40 vpn
docker compose exec vpn ip -br addr
docker compose exec vpn ip route

Հասցեների ցանկը պետք է ցույց տա թունելի ինտերֆեյս՝ փուլից վերցված հասցեով, իսկ երթուղիների աղյուսակը պետք է ցույց տա դեպի այն ուղղված հրահրված նպատակակետերը։ Եթե ինտերֆեյսը բացակայում է, հաճախորդը երբեք չի հասել այն ստեղծելու կետին։ Եթե այն կա, բայց ոչ մի երթուղի չի օգտագործում այն, որոնման տեղը push-ն է կամ երթուղու ընտրանքները։

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

Անջատված վիճակը պայմանագրի մասն է

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

Եթե աշխատանքային բեռը երբեք չպետք է օգտագործի սովորական ուղին, նախագծեք այն բացահայտ firewall-ի կանոններով և անունների տարածության ներսում պատրաստակամության ազդանշանով։ Kill switch-ը քաղաքականություն է, որը գրում և փորձարկում եք, ոչ թե հատկություն, որը ժառանգում եք կոնտեյներում հաճախորդ գործարկելուց։

Վերջապես, հիշեք սահմանը՝ այս երթուղիները ապրում են կոնտեյների անունների տարածքում և չեն փոխարինում հոսթի երթուղավորման աղյուսակը։ Docker-ի փոխանցման, թարգմանության և firewall-ի կանոնները մնում են արտաքին ուղու մաս, և հրապարակված պորտը VPN ինտերֆեյս չէ։