OpenVPN v Dockeri: zmluva o behu, ktorú potrebuje minimálny klient

Vložte VPN klienta do kontajnera a získate jeden menový priestor s tunelom vnútri, nie hostiteľa, ktorý smeruje všetku svoju prevádzku cez VPN. Sú to oddelené projekty a práve ich zlievanie do jedného vedie k tomu, že kontajnery omylom skončia privilegované. Táto príručka pokrýva len prvý prípad: jeden preverený obraz, jeden chránený profil a klientsky proces obmedzený na vlastný sieťový menový priestor.

Začnite artefaktom, ktorý už niekto schválil. Kroky nižšie predpokladajú obraz, ktorý obsahuje spustiteľný súbor openvpn a úplný klientsky profil s certifikátom a kľúčovým materiálom už vyriešeným v rámci pripojenia. Nevytvárajú softvér, nevydávajú prihlasovacie údaje a nepokrývajú prostredia bez rootu ani natívne kontajnery Windows, pričom každé z nich mení odpoveď.

Čo kontajner dostane a čo nie

Udržujte profil a všetko, na čo odkazuje, v lokálnom adresári s obmedzenými právami, pripojenom len na čítanie. Relatívne cesty v profile sa musia vyriešiť v rámci tohto pripojenia; to je detail, ktorý ľudia prehliadnu, keď certifikát leží o adresár vyššie než profil a kontajner ho nikdy nevidí.

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"]

Tento súbor dáva tri veci a nežiada nič ďalšie. Odkaz na obraz by mal byť pripnutý digestom, ak to vyžaduje vaša zásada nasadenia, a profilom by mal byť preverený, nie kópia, ktorú niekto upravil priamo na hostiteľovi.

Len na čítanie tu znamená, že kontajner nemôže meniť vaše súbory na hostiteľovi; neznamená to, že nemôže prečítať súkromný kľúč, ktorý ste pripojili. To je celý zmysel pripojenia, a preto práva k súborom, vlastníctvo a spôsob, akým sa tajomstvo dostalo na hostiteľa, stále hrajú rolu. Nikdy neodovzdávajte heslo na príkazovom riadku a nepečte ho do vrstvy obrazu, pretože oboje prežíva na miestach, ktoré neskôr nebudete môcť vyčistiť.

Schopnosti, entrypoint a pasca medzi nimi

Sú potrebné dve nastavenia a robia nesúvisiace veci. NET_ADMIN umožňuje manipuláciu s rozhraniami a trasami v menovom priestore kontajnera. Záznam zariadenia /dev/net/tun umožňuje procesu vôbec otvoriť tunelové zariadenie. Udelenie jedného bez druhého vedie k jasnému zlyhaniu, čo je výhodné: chýbajúce zariadenie TUN zlyhá pri otvorení, zatiaľ čo chýbajúca schopnosť zlyhá, keď sa klient pokúsi nakonfigurovať rozhranie.

Ani jedno z toho neospravedlňuje privileged: true. Privilegovaný kontajner dostane všetky schopnosti plus prístup k zariadeniam, a to je oveľa väčšie udelenie, než táto úloha potrebuje. referencia o oprávneniach a schopnostiach behového prostredia vysvetľuje, kam až toto udelenie siaha. Ak o to žiada chart alebo blogový príspevok, najprv skontrolujte, či požiadavkou nebola v skutočnosti chýbajúca cesta k zariadeniu alebo chýbajúca schopnosť.

Prepísanie entrypoint je tá časť, ktorá hryzie. Priame volanie openvpn je správne pre obyčajný obraz a nesprávne pre každý produktový obraz, ktorého štartovací skript pripravuje pravidlá firewallu, súbory resolvera alebo prihlasovacie údaje pred spustením démona. Prepísanie tohto skriptu preskočí prípravu a nechá vás ladiť tunel, ktorý vznikol v napoly nakonfigurovanom menovom priestore.

Spúšťajte klienta na popredí a nechajte ho byť hlavným procesom kontajnera. Proces, ktorý sa daemonizuje, okamžite skončí, kontajner sa reštartuje v slučke a protokoly, ktoré potrebujete, sú roztrúsené medzi reštartmi, ktoré všetky vyzerajú rovnako.

Overujte zvnútra menového priestoru, nie z hostiteľa

Zdvihnite stack, potvrďte v logu, že klient dosiahol pripojený stav, a potom preskúmajte menový priestor, ktorý tunel skutočne drží.

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

Zoznam adries by mal ukázať tunelové rozhranie s adresou z poolu a smerovacia tabuľka by mala ukázať posielané destinácie smerujúce naň. Ak rozhranie chýba, klient sa nikdy nedostal k jeho vytvoreniu. Ak existuje, ale žiadna trasa ho nepoužíva, hľadajte v push alebo v možnostiach trás.

Potom otestujte destináciu, na ktorej vám záleží, z menového priestoru, ktorý má tunel používať, pomocou aplikácie, nie len pingom. Preklad mien je samostatné zlyhanie, ktoré stojí za výslovné otestovanie: posielaná adresa DNS sama neaktualizuje resolver kontajnera a samostatný klient, ktorý push ignoruje, bude prekladať mená cez to, čo obraz nakonfiguroval.

Odpojený stav je súčasťou zmluvy

Správanie pri opätovnom pripojení potrebuje vlastnú kontrolu, pretože zásada reštartu dokazuje, že sa proces reštartuje, a nehovorí nič o tom, čo robí prevádzka medzitým. Zastavte tunel, vyskúšajte zamýšľanú destináciu a sledujte, či je spojenie odmietnuté, visí alebo ticho uspeje cez bežnú trasu kontajnera. Posledný výsledok je ten, na ktorom záleží, a je neviditeľný v zdravom logu.

Ak úloha nikdy nesmie použiť bežnú cestu, navrhnite to výslovne pomocou pravidiel firewallu a signálu pripravenosti v menovom priestore. Kill switch je zásada, ktorú píšete a testujete, nie vlastnosť, ktorú zdedíte spustením klienta v kontajneri.

Nakoniec pamätajte na hranicu: tieto trasy žijú v menovom priestore kontajnera a nenahrádzajú smerovaciu tabuľku hostiteľa. Pravidlá presmerovania, prekladu a firewallu v Dockeri zostávajú súčasťou vonkajšej cesty a publikovaný port nie je rozhranie VPN.