OpenVPN Docker: vykdymo sutartis, kurios reikia minimaliam klientui

Patikrintas atvaizdas, vienas apsaugotas profilis, TUN prieiga ir NET_ADMIN. Ką konteineris gauna, ko neturi gauti ir kaip įrodyti, kad tunelis veikia.

Įdėkite VPN klientą į konteinerį ir gausite vieną vardų erdvę su tuneliu viduje, o ne prieglobą, kuris visą savo srautą nukreipia per VPN. Tai atskiri projektai, ir būtent jų traktavimas kaip vieno lemia, kad konteineriai atsitiktinai tampa privilegijuoti. Šis vadovas apima tik pirmąjį atvejį: vieną patikrintą atvaizdą, vieną apsaugotą profilį ir kliento procesą, apribotą savo tinklo vardų erdve.

Pradėkite nuo artefakto, kurį kas nors jau patvirtino. Tolesni veiksmai numato atvaizdą, kuriame yra openvpn vykdomasis failas ir visas kliento profilis, kurio sertifikatas ir rakto medžiaga jau išspręsti prijungimo viduje. Jie nekuriam programinės įrangos, neišduoda kredencialų ir neapima aplinkų be root bei native Windows konteinerių, kurių kiekvienas keičia atsakymą.

Ką konteineris gauna, o ko ne

Laikykite profilį ir viską, į ką jis nurodo, vietiniame kataloge su ribotomis teisėmis, prijungtame tik skaitymui. Santykiniai keliai profilio viduje turi būti išspręsti tame prijungime; tai detalė, kurią žmonės praleidžia, kai sertifikatas yra vienu katalogu aukščiau už profilį ir konteineris jo niekada nemato.

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

Šis failas suteikia tris dalykus ir nieko daugiau neprašo. Atvaizdo nuoroda turėtų būti užfiksuota digest, jei jūsų diegimo politika taip sako, o profilis turėtų būti patikrintas, o ne kopija, kurią kas nors redagavo tiesiogiai priegloboje.

Tik skaitymui čia reiškia, kad konteineris negali keisti jūsų prieglobos failų; tai nereiškia, kad konteineris negali perskaityti jūsų prijungto privataus rakto. Tai ir yra visas prijungimo tikslas, ir todėl failų teisės, nuosavybė ir tai, kaip paslaptis pateko į prieglobą, vis dar svarbu. Niekada neperduokite slaptažodžio komandų eilutėje ir neįkepkite jo į atvaizdo sluoksnį, nes abu išlieka vietose, kurių vėliau negalėsite išvalyti.

Galimybės, entrypoint ir spąstai tarp jų

Reikia dviejų nustatymų, ir jie atlieka nesusijusius darbus. NET_ADMIN leidžia manipuliuoti sąsajomis ir maršrutais konteinerio vardų erdvėje. Įrenginio įrašas /dev/net/tun leidžia procesui apskritai atidaryti tunelio įrenginį. Davus vieną be kito gaunama aiški klaida, o tai patogu: trūkstamas TUN įrenginys nepavyksta atidarant, o trūkstama galimybė nepavyksta, kai klientas bando konfigūruoti sąsają.

Nė vienas iš jų nepateisina privileged: true. Privilegijuotas konteineris gauna visas galimybes ir prieigą prie įrenginių, ir tai yra daug didesnis suteikimas, nei reikia šiam darbo krūviui. vykdymo aplinkos privilegijų ir galimybių nuoroda paaiškina, kiek toli siekia šis suteikimas. Jei chart ar tinklaraščio įrašas to prašo, pirmiausia patikrinkite, ar reikalavimas iš tikrųjų nebuvo trūkstamas įrenginio kelias ar trūkstama galimybė.

entrypoint perrašymas yra ta dalis, kuri kandžiojasi. Tiesioginis openvpn iškvietimas yra teisingas paprastam atvaizdui ir neteisingas bet kuriam produkto atvaizdui, kurio paleidimo scenarijus prieš paleisdamas demoną paruošia ugniasienės taisykles, resolverio failus ar kredencialus. To scenarijaus perrašymas praleidžia paruošimą ir palieka jus derinti tunelį, kuris iškilo pusiau sukonfigūruotoje vardų erdvėje.

Paleiskite klientą pirmame plane ir leiskite jam būti pagrindiniu konteinerio procesu. Procesas, kuris tampa demonu, išeina iš karto, konteineris paleidžiamas iš naujo cikle, o jums reikalingi žurnalai išsibarstę tarp perkrovimų, kurie visi atrodo vienodai.

Tikrinkite iš vardų erdvės vidaus, o ne iš prieglobos

Pakelkite steką, žurnale patvirtinkite, kad klientas pasiekė prisijungusią būseną, tada apžiūrėkite vardų erdvę, kuri iš tikrųjų laiko tunelį.

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

Adresų sąraše turėtų būti tunelio sąsaja su adresu iš baseino, o maršrutų lentelėje – nukreipti į ją stumiami tikslai. Jei sąsajos nėra, klientas niekada nepasiekė jos kūrimo etapo. Jei ji yra, bet joks maršrutas jos nenaudoja, ieškoti reikia push arba maršruto parinktyse.

Tada išbandykite jums svarbų tikslą iš vardų erdvės, kuri turėtų naudoti tunelį, su programa, o ne vien su ping. Vardų sprendimas yra atskira klaida, kurią verta išbandyti aiškiai: stumiamas DNS adresas pats neatnaujina konteinerio resolverio, o savarankiškas klientas, ignoruojantis push, spręs vardus per tai, ką sukonfigūravo atvaizdas.

Atjungta būsena yra sutarties dalis

Persijungimo elgsena reikalauja atskiro patikrinimo, nes perkrovimo politika įrodo, kad procesas persikrauna, ir nieko nesako apie tai, ką tuo metu daro srautas. Sustabdykite tunelį, išbandykite numatytą tikslą ir stebėkite, ar ryšys atmetamas, užstringa, ar tyliai pavyksta įprastu konteinerio maršrutu. Paskutinis rezultatas yra tas, kuris svarbus, ir jis nematomas sveikame žurnale.

Jei darbo krūvis niekada neturi naudoti įprasto kelio, suprojektuokite tai aiškiai su ugniasienės taisyklėmis ir pasirengimo signalu vardų erdvėje. Kill switch yra politika, kurią rašote ir tikrinate, o ne savybė, kurią paveldite paleidę klientą konteineryje.

Galiausiai prisiminkite ribą: šie maršrutai gyvena konteinerio vardų erdvėje ir nepakeičia prieglobos maršrutizavimo lentelės. Docker persiuntimo, vertimo ir ugniasienės taisyklės lieka išorinio kelio dalimi, o paskelbtas prievadas nėra VPN sąsaja.

Susiję straipsniai