LXD konteyneri /dev/net/tun faylini ocholmayaptimi? unix-char yozuvini tekshiring
VPN mijozi undan foydalanishidan oldin LXD xostning TUN qurilmasini konteynerga uzatishi kerak. unix-char nima qo'shishini, nima qo'shmasligini va buni qanday tekshirishni ko'ring.
LXD xostning belgi qurilmasini konteynerga qurilma tugunini qo'shish orqali taqdim etadi, mehmonga uni yaratishni o'rgatish orqali emas. Konteynerde /dev/net/tun bo'lmasa, qurilma xostda bo'lishi mumkin va mehmon baribir uni ocholmaydi. unix-char yozuvi bu yo'lning boshqaruvchi tomonidagi yarmi bo'lib, u ataylab imtiyozli konteynerdan torroq. Shuning uchun xost tuguni va konteyner tuguni alohida tekshiruvlarga loyiq.
Mexanizm ko'z oldida ushlab turish uchun yetarlicha qisqa: LXD xost yo'lini hal qiladi, nusxa ichida mos tugun yaratadi va qurilmani konteynerning qurilma cgroup'iga qo'shadi. Keyin mehmon jarayoniga tugunni biror narsaga ishlatish uchun o'z ruxsati va qobiliyati kerak.
unix-char yozuvi aslida nima o'zgartiradi
unix-char qurilmasi LXD'ga xostning bitta belgi qurilmasini konteyner ichidagi tanlangan yo'lda taqdim etishni aytadi. Yozuvning uchta muhim qismi bor: boshqaruvchi ishlatadigan qurilma yorlig'i, xostdagi source yo'li va mehmon ko'radigan path. Faqat oxirgi ikkisi qurilmaning o'zini tasvirlaydi. Ulardan birida terish xatosi mijoz hech qachon ochmaydigan joyda tugun yaratadi.
Xostda qurilma odatda /dev/net/tun bo'ladi. Konteyner ichida siz o'sha yo'lni saqlab qolishingiz yoki boshqasini tanlashingiz mumkin, lekin yo'l VPN mijozi kutgan narsaga mos kelishi kerak. /dev/net/tun ni saqlash ikkinchi konfiguratsiya muammosidan qochadi, chunki mijozlarning aksariyati bu yo'lni so'ramasdan ochadi.
Boshqaruvchi yozuvni nusxa ishga tushganda yoki qurilma issiq ulanaganda qo'llaydi. U mehmonga drayver nusxalamaydi va tunnel interfeysi yaratmaydi. Tugunni ko'rinadigan qiladi va konteynerning qurilma nazorat guruhi orqali kirishga ruxsat beradi.
Qurilmani mehmon ichida emas, nusxada e'lon qiling
Yozuvni LXD ma'muriy kontekstidan qo'shing, nusxa va keyinroq taniydigan yorliqni nomlang. vpnbox nomli konteyner uchun buyruq quyidagicha:
lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox
tun yorlig'i nusxa konfiguratsiyasiga xos. Bu interfeys nomi emas va mehmondagi hech narsaga mos kelishi shart emas. Agar profil allaqachon o'sha qurilmani taqdim etsa, ikkinchi yozuv ortiqchalik emas, ziddiyat yaratadi, shuning uchun avval amaldagi konfiguratsiyani ko'rib chiqing.
Konteyner ichidagi fayllarni tahrirlash noto'g'ri qatlam. Ishga tushirish skriptidagi mknod imtiyozli konteynerda ishlayotgandek ko'rinib, keyin qayta yaratishda yo'qolishi yoki kamroq imtiyozli konteynerda muvaffaqiyatsiz bo'lishi mumkin. Nusxaning qurilmalar to'plami boshqaruvchiga tegishli; tugun ham unga tegishli bo'lsin.
Egalik va rejimni mehmon jarayoniga moslang
unix-char yozuvi konteyner ichidagi tugun uchun uid, gid va mode ni belgilashi mumkin. Ularni har bir foydalanuvchiga qurilmani ochish yoki konteynerni imtiyozli rejimga o'tkazish o'rniga, VPN mijozini ishga tushiruvchi hisobga moslashtirish uchun ishlating.
Ko'rinish ruxsat bilan bir xil emas. rootga tegishli va rejimi 600 bo'lgan tugun imtiyozsiz foydalanuvchi sifatida ishlayotgan xizmatga ko'rinadi va baribir u uni ocha olmaydi. Avval mehmon hisobini tekshiring, keyin egalikni shu hisobga belgilang va rejimni mijozga kerak bo'lganidan kengroq qoldirmang.
Jarayonga tunnel interfeysini sozlash qobiliyati ham kerak, odatda konteynerning tarmoq nomlar fazosida CAP_NET_ADMIN. Qurilmani uzatish bu qobiliyatni bermaydi, qobiliyatni berish esa qurilmani ta'minlamaydi; bular mustaqil talablar.
Yozuv nima bermasligini biling
Ko'rinadigan tugun ishlayotgan VPN emas. Mijoz paketini hali o'rnatish kerak, profil hali amal qilishi kerak va xizmat hali ishga tushishi kerak. Autentifikatsiya, marshrutlar va DNS mijozning ishi bo'lib qoladi, u yerdagi muvaffaqiyatsizlik esa qurilma yozuvi noto'g'ri ekaniga dalil emas.
systemd yana bir cheklov qo'shishi mumkin. DeviceAllow yoki qattiqlashtirilgan qurilma siyosati bo'lgan birlik konteyner boshqaruvchisi taqdim etgan tugunga kirishni rad etishi mumkin. Tugun mavjud bo'lsa-da xizmat ruxsat xatosini xabar qilganda birlikning qurilma siyosatini tekshiring va konteynerni kengaytirish o'rniga o'sha siyosatni o'zgartiring.
Issiq ulash ixtiyoriy va aniq. required=false bo'lgan yozuvga manba yo'li kerak va xost qurilmasi o'zgarganda paydo bo'lishi yoki yo'qolishi mumkin. Bunday hayot sikli kelib-ketadigan apparatga mos keladi; VPN yuklanishda kerak bo'ladigan TUN qurilmasi uchun ixtiyoriy yozuv xizmatni uning sharti paydo bo'lishidan oldin ishga tushirishga yo'l qo'yishi mumkin.
Ko'rinish, ochilish va interfeysni shu tartibda tekshiring
Avval mo'ljallangan konteyner ichidagi tugunni tasdiqlang. Yo'l, asosiy va kichik raqamlar hamda egalik xost qurilmasi va siz qo'shgan yozuvga mos kelishi kerak. Tugun yo'q bo'lsa, boshqaruvchi yozuvni qo'llamagan yoki uni boshqa nusxaga qo'llagan.
lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'
Keyin xizmat hisobi uni ocha olishini tasdiqlang. Shu hisob bilan qilingan qisqa sinov egalik muammosini xizmat muammosidan ajratadi. Nihoyat, mijozni ishga tushiring va tunnel interfeysi paydo bo'lganini tasdiqlang; faqat shu uchinchi qadam butun yo'lni isbotlaydi, chunki birinchi ikkisi o'tishi mumkin, mijoz profili yoki qobiliyati esa hali noto'g'ri bo'lishi mumkin.
O'zgarish tasdiqlanganda nusxa, qurilma yorlig'i, xost manbasi, mehmon yo'li va egalik hisobini yozib qo'ying. O'sha besh qiymat keyingi qayta yaratish, ko'chirish yoki profil o'zgarishi saqlashi kerak bo'lgan narsa va ularni kontekstsiz ruxsat xatosidan ancha oson taqqoslash mumkin.