Docker'dagi OpenVPN: minimal mijozga kerak bo'ladigan ishlash shartnomasi
Tekshirilgan obraz, bitta himoyalangan profil, TUN ruxsati va NET_ADMIN. Konteyner nima oladi, nima olmasligi kerak va tunnel ishlashini qanday isbotlash mumkin.
VPN mijozini konteynerga joylashtirsangiz, ichida tunnel bo'lgan bitta nomlar fazosini olasiz, butun trafigini VPN orqali yo'naltiradigan host emas. Bular alohida loyihalar, va ularni bitta deb qarash konteynerlar tasodifan imtiyozli bo'lib qolishining yo'lidir. Bu qo'llanma faqat birinchisini qamrab oladi: bitta tekshirilgan obraz, bitta himoyalangan profil va o'z tarmoq nomlar fazosi bilan cheklangan mijoz jarayoni.
Kimdir allaqachon tasdiqlagan artefaktdan boshlang. Quyidagi qadamlar openvpn bajariladigan fayli va sertifikati hamda kalit materiali mount ichida allaqachon hal qilingan to'liq mijoz profilini o'z ichiga olgan obrazni nazarda tutadi. Ular dasturiy ta'minot qurmaydi, hisob ma'lumotlarini bermaydi va root yo'q ishlash muhitlari hamda Windows'ning mahalliy konteynerlarini qamramaydi, ularning har biri javobni o'zgartiradi.
Konteyner nima oladi va nima olmaydi
Profil va u havola qilgan hamma narsani cheklangan ruxsatli mahalliy katalogda saqlang, faqat o'qish uchun mount qilingan. Profil ichidagi nisbiy yo'llar shu mount ichida hal qilinishi kerak; bu sertifikat profildan bir katalog yuqorida bo'lganda va konteyner uni hech qachon ko'rmaganda odamlar o'tkazib yuboradigan tafsilot.
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"]
Bu fayl uchta narsa beradi va boshqa hech narsa so'ramaydi. Agar joylashtirish siyosatingiz shunday desa, obraz havolasi digest bilan mahkamlanishi kerak, profil esa tekshirilgan bo'lishi kerak, hostda kimdir joyida tahrir qilgan nusxa emas.
Bu yerda faqat o'qish konteyner hostdagi fayllaringizni o'zgartira olmasligini bildiradi; siz mount qilgan shaxsiy kalitni o'qiy olmasligini bildirmaydi. Mountning butun maqsadi shu, va shuning uchun fayl ruxsatlari, egalik va sir hostga qanday kelgani hanuz muhim. Parolni hech qachon buyruq satrida bermang va uni obraz qatlamiga pishirmang, chunki ikkalasi ham keyin tozalab bo'lmaydigan joylarda qoladi.
Qobiliyatlar, entrypoint va ular orasidagi tuzoq
Ikkita sozlama kerak va ular bog'liq bo'lmagan ishlarni bajaradi. NET_ADMIN konteynerning nomlar fazosida interfeys va yo'llarni boshqarishga ruxsat beradi. /dev/net/tun qurilma yozuvi jarayonga tunnel qurilmasini umuman ochishga ruxsat beradi. Birini ikkinchisisiz berish aniq xatolik keltiradi, bu qulay: yo'q TUN qurilmasi ochishda muvaffaqiyatsiz bo'ladi, yo'q qobiliyat esa mijoz interfeysni sozlashga urinayotganda muvaffaqiyatsiz bo'ladi.
Bulardan hech biri privileged: true ni oqlamaydi. Imtiyozli konteyner barcha qobiliyatlar va qurilmalarga kirishni oladi, va bu bu ish yukiga kerak bo'lganidan ancha katta imtiyoz. ishlash muhiti imtiyozlari va qobiliyatlari bo'yicha ma'lumotnoma bu imtiyoz qanchalik uzoqqa borishini tushuntiradi. Agar chart yoki blog yozuvi buni so'rasa, avval talab haqiqatan yo'q qurilma yo'li yoki yo'q qobiliyat bo'lganini tekshiring.
entrypoint ni bekor qilish tishlaydigan qism. openvpn ni to'g'ridan-to'g'ri chaqirish oddiy obraz uchun to'g'ri va demonni ishga tushirishdan oldin firewall qoidalari, resolver fayllari yoki hisob ma'lumotlarini tayyorlaydigan har qanday mahsulot obrazi uchun noto'g'ri. O'sha skriptni bekor qilish tayyorgarlikni o'tkazib yuboradi va sizni yarim sozlangan nomlar fazosida ko'tarilgan tunnelni tuzatishga qoldiradi.
Mijozni oldingi planda ishga tushiring va u konteynerning asosiy jarayoni bo'lsin. Demonlashadigan jarayon darhol chiqadi, konteyner sikl ichida qayta ishga tushadi, va sizga kerakli jurnallar bir xil ko'rinadigan qayta ishga tushishlar orasida tarqalgan.
Nomlar fazosi ichidan tekshiring, hostdan emas
Stekni ko'taring, jurnalda mijoz ulangan holatga yetganini tasdiqlang, so'ng tunnelni haqiqatan ushlab turgan nomlar fazosini tekshiring.
docker compose up -d
docker compose logs --tail 40 vpn
docker compose exec vpn ip -br addr
docker compose exec vpn ip route
Manzillar ro'yxatida hovuzdan olingan manzilli tunnel interfeysi ko'rinishi kerak, yo'llar jadvalida esa unga qarab ko'rsatilgan surilgan manzillar ko'rinishi kerak. Agar interfeys bo'lmasa, mijoz uni yaratish nuqtasiga hech qachon yetmagan. Agar u bor bo'lsa-yu, hech bir yo'l uni ishlatmasa, qidirish joyi push yoki yo'l parametrlari.
Keyin sizga muhim bo'lgan manzilni tunnel ishlatishi kerak bo'lgan nomlar fazosidan, faqat ping emas, dastur bilan sinab ko'ring. Nomlarni hal qilish alohida xatolik bo'lib, uni aniq sinashga arziydi: surilgan DNS manzili konteynerning resolverini o'z-o'zidan yangilamaydi, va pushni e'tiborsiz qoldiradigan yakka mijoz nomlarni obraz sozlagan narsa orqali hal qiladi.
Uzilgan holat shartnomaning bir qismi
Qayta ulanish xatti-harakati o'z tekshiruvini talab qiladi, chunki qayta ishga tushirish siyosati jarayon qayta tiklanishini isbotlaydi va bu orada trafik nima qilishini aytmaydi. Tunnelni to'xtating, mo'ljallangan manzilni sinab ko'ring va ulanish rad etilishini, osilib qolishini yoki konteynerning odatiy yo'li orqali jimgina muvaffaqiyatli bo'lishini kuzating. Oxirgi natija muhim, va u sog'lom jurnalda ko'rinmaydi.
Agar ish yuki hech qachon odatiy yo'lni ishlatmasligi kerak bo'lsa, uni firewall qoidalari va nomlar fazosi ichidagi tayyorgarlik signali bilan aniq loyihalang. Kill switch siz yozadigan va sinaydigan siyosat, konteynerda mijoz ishga tushirish orqali meros qoladigan xususiyat emas.
Nihoyat, chegarani unutmang: bu yo'llar konteynerning nomlar fazosida yashaydi va hostning marshrutlash jadvalini almashtirmaydi. Docker'ning yo'naltirish, tarjima va firewall qoidalari tashqi yo'lning qismi bo'lib qoladi, va e'lon qilingan port VPN interfeysi emas.