Set in VPN-klant yn in container en jo krije ien nammromte mei in tunnel deryn, gjin host dy't al syn ferkear troch in VPN liedt. Dat binne aparte projekten, en behannelje se as ien is krekt hoe't containers by ûngelok privilezjearre wurde. Dizze hânlieding beslacht allinnich it earste: ien kontrolearre image, ien beskerme profyl en in klantproses beheind ta syn eigen netwurk-nammromte.

Begjin mei in artefakt dat immen al goedkard hat. De stappen hjirûnder ferûnderstelle in image mei it útfierbere bestân openvpn en in folslein klantprofyl wêrfan it sertifikaat en kaaimateriaal al oplost binne yn 'e mount. Se bouwe gjin software, jouwe gjin bewiisstikken út en dekke gjin rootleaze runtime-omjouwings en native Windows-containers, dy't elk it antwurd feroarje.

Wat de container krijt en wat net

Hâld it profyl en alles dêr't it nei ferwiist yn in lokale map mei beheinde rjochten, mount as allinnich-lêze. Relative paden yn it profyl moatte binnen dy mount oplost wurde; dat is in detail dat minsken misse as in sertifikaat ien map boppe it profyl stiet en de container it nea sjocht.

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

Dat bestân jout trije dingen en freget neat oars. De image-ferwizing moat fêstset wurde mei digest as jo útrôlpolitik dat seit, en it profyl moat it kontrolearre wêze, net in kopy dy't immen op it host bewurke hat.

Allinnich-lêze betsjut hjir dat de container jo hostbestannen net feroarje kin; it betsjut net dat de container de privekaai net lêze kin dy't jo montearre hawwe. Dat is it hiele punt fan 'e mount, en dêrom binne bestânsrjochten, eigendom en hoe't it geheim op it host kaam noch altyd fan belang. Jou nea in wachtwurd op 'e opdrachtline troch en bak it net yn in image-laach, want beide oerlibje op plakken dy't jo letter net opromje kinne.

Kapasiteiten, entrypoint en de falstrik dertusken

Twa ynstellingen binne nedich en se dogge net besibbe wurk. NET_ADMIN lit manipulaasje fan ynterfaces en rûtes ta yn 'e nammromte fan 'e container. De apparaatynfier /dev/net/tun lit it proses hielendal it tunnelapparaat iepenje. Ien jaan sûnder de oare leveret in dúdlik mislearjen, wat handich is: in ûntbrekkend TUN-apparaat mislearret by it iepenjen, wylst in ûntbrekkende kapasiteit mislearret as de klant it ynterface konfigurearje wol.

Gjin fan beide rjochtfeardiget privileged: true. In privilezjearre container krijt alle kapasiteiten plus apparaattagong, en dat is in folle gruttere jefte as dizze wurklast nedich hat. De referinsje oer runtime-privileezjes en kapasiteiten ferklearret hoe fier dy jefte rikt. As in chart of in blogpost it freget, kontrolearje dan earst oft de eask eins in ûntbrekkend apparaatpaad of in ûntbrekkende kapasiteit wie.

It oerskriuwen fan entrypoint is it diel dat byt. openvpn direkt oanroppe is goed foar in gewoane image en ferkeard foar elke produktimage waans startskript brânmuorrerjegels, resolverbestannen of bewiisstikken taret foar't de daemon útfierd wurdt. Dat skript oerskriuwe slacht de tarieding oer en lit jo in tunnel debugge dy't yn in heal konfigurearre nammromte omheech kaam.

Rin de klant op 'e foargrûn en lit it it haadproses fan 'e container wêze. In proses dat daemonisearret giet daliks fuort, de container start yn in lus opnij, en de logs dy't jo nedich hawwe binne ferspraat oer werstarts dy't der allegear itselde útsjen.

Ferifiearje fan binnen de nammromte, net fan it host

Set de stack omheech, befêstigje yn 'e log dat de klant in ferbûn steat berikt hat, en besjoch dan de nammromte dy't de tunnel echt hâldt.

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

De adreslist moat in tunnel-ynterface sjen litte mei in adres út 'e pool, en de rûtetabel moat de pushte bestimmings sjen litte dy't dêrhinne wize. As it ynterface ûntbrekt, hat de klant nea it punt berikt om it te meitsjen. As it bestiet mar gjin rûte brûkt it, dan is it plak om te sykjen de push of de rûte-opsjes.

Test dan de bestimming dy't jo fan belang fine, fan 'e nammromte dy't de tunnel brûke moat, mei de applikaasje en net allinnich mei in ping. Nammoplossing is in apart mislearjen dat it wurdich is eksplisyt te testen: in pusht DNS-adres fernijt de resolver fan in container net fansels, en in selsstannige klant dy't de push negearret sil nammen oplosse fia wat de image konfigurearre hat.

De ûnferbûne steat is part fan it kontrakt

Werferbinen hâlden en dragen hat syn eigen kontrôle nedich, want in werstartbelied bewist dat it proses werstart en seit neat oer wat it ferkear ûnderwilens docht. Stop de tunnel, besykje de bedoelde bestimming en sjoch oft de ferbining wegere wurdt, hinget of stilwei slagget fia de gewoane rûte fan 'e container. It lêste resultaat is dat wat telt, en it is ûnsichtber yn in sûne log.

As de wurklast nea de gewoane wei brûke mei, ûntwerp dat dan eksplisyt mei brânmuorrerjegels en in gereedheidssinjaal yn 'e nammromte. In kill switch is in belied dat jo skriuwe en testen, gjin eigenskip dy't jo ervje troch in klant yn in container te rinnen.

Tink úteinlik oan 'e grins: dizze rûtes libje yn 'e nammromte fan 'e container en ferfange de rûtetabel fan it host net. De trochstjoer-, oersettings- en brânmuorrerjegels fan Docker bliuwe part fan it bûtenste paad, en in publisearre poarte is gjin VPN-ynterface.

Relatearre artikelen