OpenVPN Dockerissa: suoritusympäristön sopimus, jonka minimaalinen asiakas tarvitsee

Laita VPN-asiakas konttiin ja saat yhden nimiavaruuden, jonka sisällä on tunneli, et isäntää joka reitittää kaiken liikenteensä VPN:n kautta. Ne ovat erillisiä projekteja, ja niiden kohteleminen yhtenä on se tapa, jolla kontit päätyvät vahingossa etuoikeutetuiksi. Tämä ohje kattaa vain ensimmäisen: yksi katsastettu image, yksi suojattu profiili ja asiakasprosessi, joka on rajattu omaan verkkonimiavaruuteensa.

Aloita artefaktista, jonka joku on jo hyväksynyt. Alla olevat vaiheet edellyttävät imagea, joka sisältää openvpn-suoritettavan tiedoston ja täydellisen asiakasprofiilin, jonka varmenne ja avainmateriaali on jo ratkaistu liitoksen sisällä. Ne eivät rakenna ohjelmistoja, myönnä tunnuksia eivätkä kata rootittomia suoritusympäristöjä tai natiiveja Windows-kontteja, joista jokainen muuttaa vastausta.

Mitä kontti saa ja mitä ei

Pidä profiili ja kaikki mihin se viittaa paikallisessa hakemistossa rajoitetuilla oikeuksilla, vain luku -tilassa liitettynä. Profiilin sisäiset suhteelliset polut on ratkaistava kyseisen liitoksen sisällä; se on yksityiskohta, joka ihmisiltä jää huomaamatta, kun varmenne on yhden hakemiston profiilin yläpuolella eikä kontti näe sitä koskaan.

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

Tuo tiedosto antaa kolme asiaa eikä pyydä mitään muuta. Image-viittaus tulisi kiinnittää digestillä, jos käyttöönottokäytäntösi niin sanoo, ja profiilin tulisi olla katsastettu eikä kopio, jota joku on muokannut paikan päällä isännällä.

Vain luku tarkoittaa tässä sitä, että kontti ei voi muuttaa isännän tiedostoja; se ei tarkoita, ettei kontti voisi lukea liittämääsi yksityistä avainta. Juuri se on liitoksen koko pointti, ja siksi tiedosto-oikeudet, omistajuus ja se, miten salaisuus päätyi isännälle, ovat edelleen merkityksellisiä. Älä koskaan välitä salasanaa komentorivillä äläkä upota sitä image-kerrokseen, koska molemmat säilyvät paikoissa, joita et voi myöhemmin siivota.

Kyvykkyydet, entrypoint ja niiden välinen ansa

Tarvitaan kaksi asetusta, ja ne tekevät toisistaan riippumattomia töitä. NET_ADMIN sallii liitäntöjen ja reittien muokkaamisen kontin nimiavaruudessa. Laitemerkintä /dev/net/tun sallii prosessin ylipäätään avata tunnelilaitteen. Toisen antaminen ilman toista tuottaa selkeän virheen, mikä on kätevää: puuttuva TUN-laite epäonnistuu avattaessa, kun taas puuttuva kyvykkyys epäonnistuu, kun asiakas yrittää määrittää liitännän.

Kumpikaan niistä ei oikeuta privileged: true. Etuoikeutettu kontti saa kaikki kyvykkyydet sekä laitekäytön, ja se on paljon suurempi myönnytys kuin tämä työkuorma tarvitsee. viittaus suoritusympäristön etuoikeuksiin ja kyvykkyyksiin selittää, kuinka pitkälle tuo myönnytys ulottuu. Jos chart tai blogikirjoitus pyytää sitä, tarkista ensin, oliko vaatimuksena todella puuttuva laitepolku tai puuttuva kyvykkyys.

entrypoint-ohituksen osuus on se, joka puree. openvpn-ohjelman suora kutsuminen on oikein tavalliselle imagelle ja väärin jokaiselle tuoteimagelle, jonka käynnistysskripti valmistelee palomuurisäännöt, resolver-tiedostot tai tunnukset ennen daemonin käynnistämistä. Tuon skriptin ohittaminen jättää valmistelun väliin ja jättää sinut selvittämään tunnelia, joka nousi puoliksi määritettyyn nimiavaruuteen.

Aja asiakas etualalla ja anna sen olla kontin pääprosessi. Prosessi, joka daemonisoituu, poistuu heti, kontti käynnistyy uudelleen silmukassa, ja tarvitsemasi lokit ovat hajallaan uudelleenkäynnistyksissä, jotka kaikki näyttävät samanlaisilta.

Vahvista nimiavaruuden sisältä, ei isännältä

Nosta pino, vahvista lokista, että asiakas saavutti yhdistetyn tilan, ja tarkastele sitten nimiavaruutta, joka todella pitää tunnelia.

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

Osoiteluettelossa pitäisi näkyä tunneliliitäntä, jolla on poolin osoite, ja reittitaulussa pitäisi näkyä pushatut kohteet, jotka osoittavat siihen. Jos liitäntä puuttuu, asiakas ei koskaan päässyt luomaan sitä. Jos se on olemassa mutta mikään reitti ei käytä sitä, etsimisen paikka on push tai reittivalinnat.

Testaa sitten sinulle tärkeä kohde nimiavaruudesta, jonka pitäisi käyttää tunnelia, sovelluksella eikä vain pingillä. Nimien selvitys on erillinen virhe, joka kannattaa testata nimenomaisesti: pushattu DNS-osoite ei päivitä kontin resolveria itsestään, ja pushin sivuuttava itsenäinen asiakas selvittää nimet sen kautta, minkä image on määrittänyt.

Yhteydettömässä tilassa oleminen on osa sopimusta

Uudelleenyhdistämiskäyttäytyminen tarvitsee oman tarkistuksensa, koska uudelleenkäynnistyskäytäntö todistaa, että prosessi käynnistyy uudelleen, eikä kerro mitään siitä, mitä liikenne tekee välillä. Pysäytä tunneli, kokeile aiottua kohdetta ja katso, hylätäänkö yhteys, jääkö se roikkumaan vai onnistuuko se hiljaa kontin tavallisen reitin kautta. Viimeinen lopputulos on se, jolla on merkitystä, ja se on näkymätön terveessä lokissa.

Jos työkuorma ei saa koskaan käyttää tavallista polkua, suunnittele se nimenomaisesti palomuurisäännöillä ja nimiavaruuden sisäisellä valmiussignaalilla. Kill switch on käytäntö, jonka kirjoitat ja testaat, ei ominaisuus, jonka perit ajamalla asiakasta kontissa.

Muista lopuksi raja: nämä reitit elävät kontin nimiavaruudessa eivätkä korvaa isännän reititystaulua. Dockerin edelleenlähetys-, käännös- ja palomuurisäännöt ovat edelleen osa ulointa polkua, eikä julkaistu portti ole VPN-liitäntä.