Docker-də OpenVPN: minimal klientin ehtiyac duyduğu icra müqaviləsi

VPN klientini konteynerə qoyun və içinə tunel yerləşmiş bir ad məkanı alırsınız, bütün trafikini VPN-dən keçirən host deyil. Bunlar ayrı layihələrdir və onlara bir layihə kimi baxmaq konteynerlərin təsadüfən imtiyazlı olmasına gətirib çıxarır. Bu təlimat yalnız birincisini əhatə edir: bir yoxlanılmış obraz, bir qorunan profil və öz şəbəkə ad məkanı ilə məhdudlaşan klient prosesi.

Kiminsə artıq təsdiqlədiyi artefaktdan başlayın. Aşağıdakı addımlar openvpn icra faylını və sertifikatı ilə açar materialı montajın içində artıq həll edilmiş tam klient profilini ehtiva edən obrazı nəzərdə tutur. Onlar proqram qurmur, etimadnamə yaratmır və köksüz işləmə mühitlərini və yerli Windows konteynerlərini əhatə etmir; hər biri cavabı dəyişir.

Konteynerin nə aldığı və nə almadığı

Profili və onun istinad etdiyi hər şeyi məhdud icazələrlə yerli qovluqda saxlayın və yalnız oxunaq kimi montaj edin. Profildəki nisbi yollar həmin montaj daxilində həll olunmalıdır; sertifikat profildən bir qovluq yuxarıda olduqda və konteyner onu heç vaxt görmədikdə insanların qaçırdığı detallardan biri budur.

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 üç şey verir və başqa heç nə istəmir. Yerləşdirmə siyasətiniz belə deyirsə, obraz istinadı dayjest ilə bərkidilməlidir və profil hostda kiminsə yerindəcə redaktə etdiyi surət deyil, yoxlanılmış profil olmalıdır.

Burada yalnız oxunaq o deməkdir ki, konteyner host fayllarınızı dəyişə bilməz; montaj etdiyiniz şəxsi açarı oxuya bilməz demək deyil. Montajın bütün məqsədi budur və buna görə də fayl icazələri, sahiblik və sirrin hosta necə gəldiyi hələ də vacibdir. Şifrəni heç vaxt əmr sətrində ötürməyin və ya obraz qatına yerləşdirməyin, çünki hər ikisi sonradan təmizləyə bilməyəcəyiniz yerlərdə qalır.

İmkanlar, entrypoint və aralarındakı tələ

İki parametr lazımdır və onlar bir-biri ilə əlaqəsiz işlər görür. NET_ADMIN konteynerin ad məkanı daxilində interfeys və marşrut manipulyasiyasına icazə verir. /dev/net/tun cihaz girişi prosesə tunel cihazını ümumiyyətlə açmağa imkan verir. Birini digəri olmadan vermək aydın nasazlıq yaradır, bu da rahatdır: olmayan TUN cihazı açılış zamanı uğursuz olur, olmayan imkan isə klient interfeysi konfiqurasiya etməyə çalışdıqda uğursuz olur.

Bunlardan heç biri privileged: true əsaslandırmır. İmtiyazlı konteyner bütün imkanları üstəgəl cihaz çıxışını alır və bu, bu iş yükünün ehtiyacından qat-qat böyük bir imtiyazdır. icra imtiyazları və imkanlar məlumatı bu imtiyazın hara qədər çatdığını izah edir. Əgər chart və ya bloq yazısı bunu tələb edirsə, əvvəlcə yoxlayın: tələb həqiqətən çatışmayan cihaz yolu idi, yoxsa çatışmayan imkan?

entrypoint üzərinə yazmaq dişləyən hissədir. openvpn proqramını birbaşa çağırmaq adi obraz üçün düzgün, başlatma skripti demonu işə salmazdan əvvəl firewall qaydaları, resolver faylları və ya etimadnamələr hazırlayan istənilən məhsul obrazı üçün isə səhvdir. Həmin skriptin üzərinə yazmaq hazırlığı atlayır və sizi yarımkonfiqurasiya edilmiş ad məkanında qalxmış tuneli sazlamağa qoyur.

Klienti ön planda işlədin və onun konteynerin əsas prosesi olmasına icazə verin. Demonlaşan proses dərhal çıxır, konteyner dövrə ilə yenidən başlayır və ehtiyac duyduğunuz jurnallar hər biri eyni görünən yenidən başlatmalar arasında səpələnir.

Ad məkanının içindən yoxlayın, hostdan deyil

Steki qaldırın, jurnalda klientin qoşulmuş vəziyyətə çatdığını təsdiqləyin və sonra tuneli həqiqətən saxlayan ad məkanını yoxlayın.

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

Ünvan siyahısı hovuzdan ünvanı olan tunel interfeysini göstərməli, marşrut cədvəli isə ona yönələn ötürülmüş təyinatları göstərməlidir. İnterfeys yoxdursa, klient onu yaratma nöqtəsinə heç vaxt çatmayıb. Mövcuddursa, lakin heç bir marşrut ondan istifadə etmirsə, axtarılacaq yer push və ya marşrut seçimləridir.

Sonra əhəmiyyət verdiyiniz təyinatı tuneldən istifadə etməli olan ad məkanından, yalnız ping ilə deyil, tətbiqlə sınayın. Ad həlli ayrı bir nasazlıqdır və açıq şəkildə sınanmağa dəyər: ötürülmüş DNS ünvanı konteynerin resolverini özlüyündə yeniləmir və push-u nəzərə almayan müstəqil klient adları obrazın konfiqurasiya etdiyi vasitə ilə həll edəcək.

Bağlantısız vəziyyət müqavilənin bir hissəsidir

Yenidən qoşulma davranışı öz yoxlamasını tələb edir, çünki yenidən başlatma siyasəti prosesin yenidən başladığını sübut edir və arada trafikin nə etdiyi barədə heç nə demir. Tuneli dayandırın, nəzərdə tutulan təyinatı yoxlayın və bağlantının rədd edildiyini, asılı qaldığını və ya konteynerin adi marşrutu ilə səssizcə uğur qazandığını izləyin. Sonuncu nəticə əhəmiyyətli olandır və sağlam jurnalda görünmür.

Əgər iş yükü heç vaxt adi yoldan istifadə etməməlidirsə, bunu firewall qaydaları və ad məkanı daxilində hazırlıq siqnalı ilə açıq şəkildə layihələndirin. Kill switch yazdığınız və sınadığınız siyasətdir, konteynerdə klient işlətməklə miras aldığınız xüsusiyyət deyil.

Nəhayət, sərhədi xatırlayın: bu marşrutlar konteynerin ad məkanında yaşayır və hostun marşrut cədvəlini əvəz etmir. Docker-in yönləndirmə, tərcümə və firewall qaydaları xarici yolun bir hissəsi olaraq qalır və dərc edilmiş port VPN interfeysi deyil.