OpenVPN Dockeris: täitmiskeskkonna leping, mida minimaalne klient vajab

Pange VPN-klient konteinerisse ja saate ühe nimeruumi, mille sees on tunnel, mitte hosti, mis suunab kogu oma liikluse VPN-i kaudu. Need on eraldi projektid ja nende üheks pidamine on viis, kuidas konteinerid kogemata privilegeerituks muutuvad. See juhend katab ainult esimest: üks üle vaadatud pilt, üks kaitstud profiil ja kliendi protsess, mis on piiratud oma võrgu nimeruumiga.

Alustage artefaktist, mille keegi on juba heaks kiitnud. Alltoodud sammud eeldavad pilti, mis sisaldab käivitatavat faili openvpn ja täielikku kliendiprofiili, mille sertifikaat ja võtmematerjal on mounti sees juba lahendatud. Need ei ehita tarkvara, ei väljasta mandaate ega kata root-õigusteta keskkondi ega Windowsi natiivseid konteinereid, millest igaüks muudab vastust.

Mida konteiner saab ja mida mitte

Hoidke profiili ja kõike, millele see viitab, kohalikus kataloogis piiratud õigustega, ainult lugemiseks mountituna. Profiili sees olevad suhtelised teed peavad lahenema selle mounti sees; see on detail, mille inimesed jätavad märkamata, kui sertifikaat asub profiilist ühe kataloogi võrra kõrgemal ja konteiner ei näe seda kunagi.

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

See fail annab kolm asja ega küsi midagi muud. Pildiviide tuleks kinnitada digesti abil, kui teie juurutuspoliitika seda nõuab, ja profiil peaks olema üle vaadatud, mitte koopia, mida keegi hostis kohapeal muutis.

Ainult lugemiseks tähendab siin, et konteiner ei saa teie hostifaile muuta; see ei tähenda, et konteiner ei saa lugeda teie mountitud privaatvõtit. See ongi mountimise mõte ja seetõttu on failiõigused, omand ja see, kuidas saladus hosti jõudis, endiselt olulised. Ärge kunagi edastage parooli käsureal ega küpsetage seda pildikihiks, sest mõlemad jäävad ellu kohtades, mida te hiljem puhastada ei saa.

Võimed, entrypoint ja nende vaheline lõks

Vaja on kahte seadet ja need teevad mitteseotud töid. NET_ADMIN lubab liideste ja marsruutidega manipuleerida konteineri nimeruumis. Seadme kirje /dev/net/tun lubab protsessil tunneleeadet üldse avada. Ühe andmine ilma teiseta tekitab selge tõrke, mis on mugav: puuduv TUN-seade ebaõnnestub avamisel, samas kui puuduv võime ebaõnnestub siis, kui klient üritab liidest konfigureerida.

Kumbki neist ei õigusta privileged: true. Privilegeeritud konteiner saab kõik võimed pluss juurdepääsu seadmetele ja see on palju suurem luba, kui see töökoormus vajab. viide käituskeskkonna privileegidele ja võimetele selgitab, kui kaugele see luba ulatub. Kui chart või blogipostitus seda küsib, kontrollige esmalt, kas nõue oli tegelikult puuduv seadmepath või puuduv võime.

entrypoint alistamine on see osa, mis hammustab. openvpn otse kutsumine on õige tavalise pildi jaoks ja vale iga tootepildi jaoks, mille algskript valmistab ette tulemüürireeglid, resolverifailid või mandaadid enne deemonit käivitamist. Selle skripti alistamine jätab ettevalmistuse vahele ja jätab teid siluma tunnelit, mis tõusis pooleldi konfigureeritud nimeruumis.

Käivitage klient esiplaanil ja laske sellel olla konteineri põhiprotsess. Protsess, mis daemoniseerub, väljub kohe, konteiner taaskäivitub tsüklis ja vajalikud logid on laiali taaskäivituste vahel, mis kõik näevad ühesugused välja.

Kontrollige nimeruumi seest, mitte hostist

Tõstke stack üles, kinnitage logis, et klient jõudis ühendatud olekusse, ja seejärel uurige nimeruumi, mis tunnelit tegelikult hoiab.

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

Aadresside loend peaks näitama tunneli liidest basseinist pärit aadressiga ja marsruuditabel peaks näitama sinna suunatud pushitud sihtkohti. Kui liidest pole, ei jõudnud klient kunagi selle loomiseni. Kui see on olemas, aga ükski marsruut seda ei kasuta, tuleb otsida pushist või marsruudivalikutest.

Seejärel testige sihtkohta, mis teile tähtis on, nimeruumist, mis peaks tunnelit kasutama, rakendusega, mitte ainult pingiga. Nimelahendus on eraldi tõrge, mida tasub selgesõnaliselt testida: pushitud DNS-aadress ei uuenda konteineri resolverit iseenesest ja iseseisev klient, mis pushi eirab, lahendab nimesid selle kaudu, mille pilt on konfigureerinud.

Ühendamata olek on lepingu osa

Taasühendumise käitumine vajab oma kontrolli, sest taaskäivitamispoliitika tõestab, et protsess käivitub uuesti, ega ütle midagi selle kohta, mida liiklus vahepeal teeb. Peatage tunnel, proovige kavandatud sihtkohta ja jälgige, kas ühendus lükatakse tagasi, jääb rippuma või õnnestub vaikselt konteineri tavalisel marsruudil. Viimane tulemus on see, mis loeb, ja see on terves logis nähtamatu.

Kui töökoormus ei tohi kunagi tavalist teed kasutada, kavandage see selgesõnaliselt tulemüürireeglite ja nimeruumi sees oleva valmidussignaaliga. Kill switch on poliitika, mille te kirjutate ja testite, mitte omadus, mille pärite klienti konteineris käivitades.

Lõpuks pidage meeles piiri: need marsruudid elavad konteineri nimeruumis ega asenda hosti marsruutimistabelit. Dockeri edastus-, tõlke- ja tulemüürireeglid jäävad välise tee osaks ja avaldatud port ei ole VPN-liides.