OpenVPN i Docker: køyretidskontrakten ein minimal klient treng

Set ein VPN-klient i ein container og du får eitt namnerom med ein tunnel inni, ikkje ein vert som ruter all trafikken sin gjennom ein VPN. Dette er separate prosjekt, og det å handsame dei som eitt er nettopp måten containerar endar opp med privilegium ved eit uhell. Denne rettleiinga dekkjer berre det første: eit gjennomgått image, éin verna profil og ein klientprosess avgrensa til sitt eige nettverksnamnerom.

Start med eit artefakt som nokon allereie har godkjent. Stega nedanfor føreset eit image som inneheld den køyrbare fila openvpn og ein fullstendig klientprofil med sertifikat og nøkkelmateriale allereie løyst inne i monteringa. Dei byggjer ikkje programvare, gjev ikkje ut påloggingsdata og dekkjer ikkje rootlause køyretidsmiljø eller native Windows-containerar, som kvar for seg endrar svaret.

Kva containeren får og ikkje får

Hald profilen og alt han viser til i ei lokal mappe med avgrensa rettar, montert skriveverna. Relative stiar i profilen må løysast innanfor monteringa; dette er ein detalj folk overser når eit sertifikat ligg éi mappe over profilen og containeren aldri ser det.

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

Den fila gjev tre ting og krev ikkje noko anna. Imagereferansen bør festast med digest om distribusjonspolitikken din seier det, og profilen bør vere den gjennomgåtte, ikkje ei kopi nokon har endra på plass på verten.

Skriveverna her tyder at containeren ikkje kan endre filene dine på verten; det tyder ikkje at containeren ikkje kan lese den private nøkkelen du monterte. Det er heile poenget med monteringa, og difor spelar filrettar, eigarskap og korleis hemmelegheita kom inn på verten framleis ei rolle. Gje aldri eit passord på kommandolinja og bak det aldri inn i eit imagelag, for begge overlever på stader du ikkje kan rydde seinare.

Kapasitetar, entrypoint og fella mellom dei

Det trengst to innstillingar og dei gjer usamanhengande arbeid. NET_ADMIN lèt deg manipulere grensesnitt og ruter i namnerommet til containeren. Apparatoppføringa /dev/net/tun lèt prosessen i det heile opne tunneleininga. Å gje den eine utan den andre gjev ein tydeleg feil, noko som er praktisk: ei manglande TUN-eining feilar ved opning, medan ein manglande kapasitet feilar når klienten prøver å konfigurere grensesnittet.

Ingen av dei rettferdiggjer privileged: true. Ein privilegert container får alle kapasitetar pluss tilgang til einingar, og det er ei mykje større løyving enn denne arbeidsmengda treng. referansen om køyretidsprivilegium og kapasitetar forklarer kor langt den løyvinga når. Om ein chart eller eit blogginnlegg ber om det, sjekk først om kravet eigentleg var ein manglande einingveg eller ein manglande kapasitet.

Overstyringa av entrypoint er den delen som bit. Å kalle openvpn direkte er rett for eit vanleg image og gale for eit kvart produktimage der oppstartsskriptet førebur brannmurreglar, resolverfiler eller påloggingsdata før daemonen blir køyrt. Å overstyre det skriptet hoppar over førebuinga og lèt deg feilsøkje ein tunnel som kom opp i eit halvkonfigurert namnerom.

Køyr klienten i framgrunnen og læt han vere hovudprosessen til containeren. Ein prosess som daemoniserer, går ut med ein gong, containeren startar på nytt i ei løkke, og loggane du treng er spreidde over omstartar som alle ser like ut.

Stadfest innanfrå namnerommet, ikkje frå verten

Reis stakken, stadfest i loggen at klienten nådde ein tilkopla tilstand, og undersøk deretter namnerommet som faktisk held tunnelen.

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

Adresselista bør vise eit tunnelgrensesnitt med ei adresse frå bassenget, og rutetabellen bør vise dei pusha måla som peikar mot det. Om grensesnittet manglar, nådde klienten aldri fram til å lage det. Om det finst men inga rute brukar det, er staden å leite push eller rutevala.

Test deretter målet du bryr deg om, frå namnerommet som skal bruke tunnelen, med programmet og ikkje berre med ping. Namneløysing er ein separat feil som er verd å teste eksplisitt: ei pusha DNS-adresse oppdaterer ikkje resolvaren til ein container av seg sjølv, og ein sjølvstendig klient som ignorerer pushen vil løyse namn gjennom det imaget har konfigurert.

Den fråkopla tilstanden er ein del av kontrakten

Gjenoppkoplingsåtferd treng si eiga kontroll, for ein omstartspolitikk beviser at prosessen startar på nytt og seier ingenting om kva trafikken gjer i mellomtida. Stopp tunnelen, prøv det tiltenkte målet og sjå om sambandet blir avvist, heng eller lukkast stille gjennom den vanlege ruta til containeren. Det siste utfallet er det som tel, og det er usynleg i ein sunn logg.

Om arbeidsmengda aldri må bruke den vanlege vegen, design det eksplisitt med brannmurreglar og eit beredskapssignal i namnerommet. Kill switch er ein politikk du skriv og testar, ikkje ein eigenskap du arvar ved å køyre ein klient i ein container.

Til slutt, hugs grensa: desse rutene lever i namnerommet til containeren og erstattar ikkje rutetabellen til verten. Docker sine videresendings-, omsetjings- og brannmurreglar er framleis ein del av den ytre vegen, og ein publisert port er ikkje eit VPN-grensesnitt.