OpenVPN v Dockerju: pogodba o izvajanju, ki jo potrebuje minimalni odjemalec

Preverjena slika, en zaščiten profil, dostop do TUN in NET_ADMIN. Kaj dobi container, česa ne sme dobiti in kako dokazati, da tunel deluje.

Vstavite odjemalca VPN v container in dobite en imenski prostor s tunelom v njem, ne gostitelja, ki vso svojo promet usmerja skozi VPN. To so ločeni projekti, in prav obravnavanje kot enega vodi do tega, da containerji pomotoma postanejo privilegirani. Ta priročnik pokriva le prvi primer: eno preverjeno sliko, en zaščiten profil in odjemalski proces, omejen na svoj omrežni imenski prostor.

Začnite z artefaktom, ki ga je nekdo že odobril. Spodnji koraki predpostavljajo sliko, ki vsebuje izvršljivo datoteko openvpn in popoln odjemalski profil s certifikatom in ključnim gradivom, že razrešenim znotraj priklopa. Ne gradijo programske opreme, ne izdajajo poverilnic in ne pokrivajo okolij brez roota niti izvornih containerjev Windows, vsak od teh pa spremeni odgovor.

Kaj container dobi in česa ne

Profil in vse, na kar se sklicuje, hranite v lokalni mapi z omejenimi pravicami, priklopljeni samo za branje. Relativne poti v profilu se morajo razrešiti znotraj tega priklopa; to je podrobnost, ki jo ljudje spregledajo, ko je certifikat eno mapo nad profilom in ga container nikoli ne vidi.

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

Ta datoteka daje tri stvari in ne zahteva ničesar drugega. Referenco slike je treba pripeti z digestom, če tako pravi vaša politika uvajanja, profil pa mora biti preverjeni, ne kopija, ki jo je nekdo uredil na mestu na gostitelju.

Samo za branje tukaj pomeni, da container ne more spreminjati vaših datotek na gostitelju; ne pomeni, da ne more prebrati zasebnega ključa, ki ste ga priklopili. To je ves smisel priklopa, zato pravice datotek, lastništvo in način, kako je skrivnost prišla na gostitelja, še vedno štejejo. Nikoli ne posredujte gesla v ukazni vrstici in ga ne vpečite v plast slike, ker oboje preživi na mestih, ki jih pozneje ne boste mogli očistiti.

Zmožnosti, entrypoint in past med njima

Potrebni sta dve nastavitvi in opravljata nepovezano delo. NET_ADMIN omogoča manipulacijo vmesnikov in poti v imenskem prostoru containerja. Vnos naprave /dev/net/tun omogoča procesu, da sploh odpre tunelsko napravo. Če daste eno brez druge, dobite jasno napako, kar je priročno: manjkajoča naprava TUN spodleti pri odpiranju, medtem ko manjkajoča zmožnost spodleti, ko odjemalec poskuša konfigurirati vmesnik.

Nobeno od tega ne upravičuje privileged: true. Privilegirani container dobi vse zmožnosti in dostop do naprav, kar je veliko večja dodelitev, kot jo ta delovna obremenitev potrebuje. referenca o privilegijih in zmožnostih izvajalnega okolja pojasnjuje, kako daleč sega ta dodelitev. Če chart ali blog objava to zahteva, najprej preverite, ali zahteva v resnici ni bila manjkajoča pot naprave ali manjkajoča zmožnost.

Prepisovanje entrypoint je del, ki ugrizne. Neposreden klic openvpn je pravilen za običajno sliko in napačen za vsako produktno sliko, katere zagonska skripta pripravi pravila požarnega zidu, datoteke resolverja ali poverilnice, preden zažene demon. Prepisovanje te skripte preskoči pripravo in vas pusti z razhroščevanjem tunela, ki je vstal v napol konfiguriranem imenskem prostoru.

Zaženite odjemalca v ospredju in pustite, da je glavni proces containerja. Proces, ki se demonizira, takoj izstopi, container se znova zažene v zanki, dnevniki, ki jih potrebujete, pa so raztreseni po ponovnih zagonih, ki vsi izgledajo enako.

Preverjajte znotraj imenskega prostora, ne z gostitelja

Dvignite sklad, v dnevniku potrdite, da je odjemalec dosegel povezano stanje, nato preglejte imenski prostor, ki dejansko drži tunel.

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

Seznam naslovov bi moral pokazati vmesnik tunela z naslovom iz bazena, usmerjevalna tabela pa bi morala pokazati potisnjene cilje, ki kažejo nanj. Če vmesnika ni, odjemalec ni nikoli prišel do njegovega ustvarjanja. Če obstaja, a ga nobena pot ne uporablja, je treba iskati pri push ali pri možnostih poti.

Nato preizkusite cilj, ki vam je pomemben, iz imenskega prostora, ki naj bi uporabljal tunel, z aplikacijo in ne le s pingom. Razreševanje imen je ločena okvara, ki si zasluži izrecen preizkus: potisnjen naslov DNS sam ne posodobi resolverja containerja, samostojni odjemalec, ki push ignorira, pa bo imena razreševal prek tega, kar je konfigurirala slika.

Odklopljeno stanje je del pogodbe

Vedenje pri ponovnem povezovanju potrebuje lastno preverjanje, ker politika znova zagona dokazuje, da se proces znova zažene, in ne pove ničesar o tem, kaj promet počne vmes. Ustavite tunel, poskusite predvideni cilj in opazujte, ali je povezava zavrnjena, visi ali tiho uspe po običajni poti containerja. Zadnji izid je tisti, ki šteje, in v zdravem dnevniku je neviden.

Če delovna obremenitev ne sme nikoli uporabiti običajne poti, to izrecno načrtujte s pravili požarnega zidu in signalom pripravljenosti v imenskem prostoru. Kill switch je politika, ki jo napišete in preizkusite, ne lastnost, ki jo podedujete z izvajanjem odjemalca v containerju.

Na koncu ne pozabite na mejo: te poti živijo v imenskem prostoru containerja in ne nadomestijo usmerjevalne tabele gostitelja. Pravila posredovanja, prevajanja in požarnega zidu Dockerja ostajajo del zunanje poti, in objavljena vrata niso vmesnik VPN.

Sorodni članki