OpenVPN Docker-en: bezero minimo batek behar duen exekuzio-kontratua

Jarri VPN bezero bat edukiontzi batean eta barruan tunel bat duen izen-tarte bat lortuko duzu, VPN bidez bere trafiko guztia bideratzen duen ostalari bat ez. Proiektu bereiziak dira, eta bat balira bezala tratatzea da edukiontziak ustekabean pribilegiatuak izatera iristeko modua. Eskuliburu honek lehenengoa bakarrik hartzen du: berrikusitako irudi bat, profil babestu bat eta bere sareko izen-tartera mugatutako bezero prozesu bat.

Hasi norbaitek dagoeneko onartu duen artefaktu batekin. Beheko urratsek openvpn exekutagarria eta bezero-profil oso bat dituen irudia suposatzen dute, ziurtagiria eta gako-materiala muntaiaren barruan jada ebatzita dituela. Ez dute softwarea eraikitzen, ez dute kredentzialik sortzen eta ez dituzte root gabeko exekuzio-inguruneak ezta Windows edukiontzi natiboak ere hartzen, horietako bakoitzak erantzuna aldatzen baitu.

Edukiontziak zer lortzen duen eta zer ez

Edu profil eta hark erreferentziatzen duen guztia baimen mugatuko direktorio lokal batean, irakurtzeko soilik muntatuta. Profileko bide erlatiboek muntai horren barruan ebazten dute; xehetasun hori jendeak ahazten du ziurtagiria profilaren direktorio bat gorago dagoenean eta edukiontziak inoiz ikusten ez duenean.

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

Fitxategi horrek hiru gauza ematen ditu eta ez du besterik eskatzen. Irudiaren erreferentzia digest bidez finkatu behar da zure hedapen-politikak hala esaten badu, eta profilak berrikusitakoa izan behar du, norbaitek ostalarian bertan editatu duen kopia bat ez.

Irakurtzeko soilik hemen edukiontziak zure ostalari-fitxategiak aldatu ezin dituela esan nahi du; ez du esan nahi muntatu duzun gako pribatua irakur ezin duenik. Horixe da muntaiaren xede osoa, eta horregatik fitxategi-baimenek, jabetzak eta sekretua ostalarira nola iritsi zen garrantzia dute oraindik. Inoiz ez ezazu pasahitzik pasatu komando-lerrotik ez eta irudi-geruza batean txertatu, biak gero garbitu ezin dituzun tokietan bizirik irauten baitute.

Gaitasunak, entrypoint eta bien arteko tranpa

Bi ezarpen behar dira eta elkarren arteko loturarik gabeko lanak egiten dituzte. NET_ADMIN edukiontziaren izen-tartean interfazeak eta bideak manipulatzeko aukera ematen du. /dev/net/tun gailu-sarrerak prozesuari tunel-gailua irekitzea ahalbidetzen dio. Bat bestea gabe emateak hutsegite argia eragiten du, eta hori erosoa da: falta den TUN gailuak irekitzean huts egiten du, eta falta den gaitasunak huts egiten du bezeroak interfazea konfiguratzen saiatzen denean.

Bi horietako batek ere ez du privileged: true justifikatzen. Edukiontzi pribilegiatu batek gaitasun guztiak eta gailuetarako sarbidea jasotzen ditu, eta lan-karga honek behar duena baino askoz emate handiagoa da. exekuzio-ingurunearen pribilegio eta gaitasunen erreferentzia azaltzen du zenbateraino iristen den emate hori. Chart edo blogeko sarrera batek eskatzen badu, egiaztatu lehenengo baldintza gailu-bide bat falta izana zela edo gaitasun bat falta izana zela.

entrypoint gainidaztea da hozka egiten duen zatia. openvpn zuzenean deitzea zuzena da irudi arrunt baterako eta okerra da abio-scriptak firewall arauak, resolver fitxategiak edo kredentzialak deabrua abiatu aurretik prestatzen dituen edozein produktu-irudirentzat. Script hori gainidazteak prestaketa saltatzen du eta erdi konfiguratutako izen-tarte batean sortu zen tunel bat arazten uzten zaitu.

Exekutatu bezeroa aurreko planoan eta utzi edukiontziaren prozesu nagusia izaten. Deabrutzen den prozesu bat berehala irteten da, edukiontzia begizta batean berrabiarazten da, eta behar dituzun logak berdinak diruditen berrabiarazteen artean sakabanatuta daude.

Egiaztatu izen-tartearen barrualdetik, ez ostalaritik

Igo stacka, egiaztatu logean bezeroa konektatutako egoerara iritsi dela, eta gero ikuskatu tunela benetan edukitzen duen izen-tartea.

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

Helbide-zerrendak pooleko helbide bat duen tunel-interfaze bat erakutsi behar du, eta bide-taulak hara bideratzen diren push egindako helmugak erakutsi behar ditu. Interfazea falta bada, bezeroa ez da inoiz hura sortzera iritsi. Badago baina bide batek ere ez badu erabiltzen, bilatzeko lekua push edo bide-aukerak dira.

Gero probatu axola zaizun helmuga, tunela erabili behar duen izen-tartetik, aplikazioarekin eta ez ping batekin soilik. Izenen ebazpena bereizitako hutsegitea da eta merezi du berariaz probatzea: push egindako DNS helbideak ez du edukiontziaren resolverra bere kabuz eguneratzen, eta pusha alde batera uzten duen bezero autonomoak irudiak konfiguratutakoaren bidez ebatziko ditu izenak.

Konektatu gabeko egoera kontratuaren parte da

Berkonexiorako jokabideak bere egiaztapena behar du, berrabiarazte-politika batek prozesua berrabiarazten dela frogatzen baitu eta ez baitu ezer esaten trafikoak tartean zer egiten duen. Gelditu tunela, saiatu nahi duzun helmuga eta begiratu konexioa ukatzen den, zintzilik geratzen den edo edukiontziaren ohiko bidetik isilka ondo ateratzen den. Azken emaitza da axola duena, eta log osasuntsu batean ikusezina da.

Lan-kargak inoiz ohiko bidea erabili behar ez badu, diseinatu hori berariaz firewall arauekin eta izen-tartearen barruko prestasun-seinale batekin. Kill switch idazten eta probatzen duzun politika bat da, ez edukiontzi batean bezero bat exekutatuz heredatzen duzun propietatea.

Azkenik, gogoratu muga: bide hauek edukiontziaren izen-tartean bizi dira eta ez dituzte ostalariaren bideratze-taula ordezkatzen. Docker-en birbidalketa, itzultze eta firewall arauak kanpoko bidearen parte izaten jarraitzen dute, eta argitaratutako ataka ez da VPN interfaze bat.