NET_ADMIN egy VPN-konténerben: mit és hol változtathat

A képesség interfész-, útvonal- és tűzfalmódosításokat tesz lehetővé egyetlen hálózati névtéren belül. Hoszthálózat esetén ez a névtér maga a hoszt verme.

NET_ADMIN az a Linux-képesség, amely lehetővé teszi egy folyamat számára a hálózati adminisztrációt, és egy konténerben pontosan ezt teszi abban a hálózati névtérben, amelyben a folyamat fut. Ez nem licenc socket megnyitására, és nem helyettesíti az eszközt vagy az útvonalat. Az érdekes kérdés soha nem az, hogy a képesség meg van-e adva, hanem hogy melyik névtér kapja a változtatást.

Mit fed le a képesség

A névterén belül a NET_ADMIN birtokában lévő folyamat fel- és leviheti az interfészeket, címeket rendelhet, útvonalakat adhat hozzá és törölhet, valamint tűzfalszabályokat írhat, ami az a műveletcsoport, amelyet a capabilities(7) e képesség alatt összegyűjt. Beállíthat interfészszintű paramétereket is, amelyek szabályozzák, hogyan sorba állítja és szűri a kernel a forgalmat. Egy VPN-kliensnek általában néhányra van szüksége indításkor, és utána semmi másra. Ezért a legtöbb image nagyobb hatáskört kér, mint amit használ.

A névtéren kívüli műveletek nem tartoznak ide, és a szomszédos jogosultságok különállóak. A nyers csomagok olvasása és írása a NET_RAW alá tartozik, a tun eszköz létrehozásához pedig a képesség és az eszközcsomóponthoz való hozzáférés is kell. Az eszköz nélküli folyamat olyan engedélyhibát kap, amely hálózati problémának látszik, és nem az.

A névtér határozza meg a kár mértékét

A saját hídhálózatán lévő konténer eléri a saját loopbackjét, a saját interfészeit és a saját útvonaltábláját. Ott a NET_ADMIN megadása lehetővé teszi a VPN-kliensnek, hogy a hoszt útvonal-döntéseit nem érintve építsen alagutat, ami az az elrendezés, amelyet a legtöbb konténerimage feltételez.

Váltsa át ezt a konténert hoszthálózatra, és ugyanez a megadás most a hoszt útvonalait és a hoszt tűzfalát szerkeszti, mert nem maradt külön névtér. A kliens, amelynek egyetlen alagutat kellett kezelnie, ekkor az egész gép forgalmát átirányíthatja, és a lebontási szkriptjében lévő hiba olyan szabályokat hagy a hoszton, amelyeket senki nem írt. Magában a képességben semmi sem változott; a kontextus változott. Ezért viselkedik ugyanaz a compose-fájl két hoszton másképp.

Három előfeltétel, amely eggyé olvad

A VPN-konténerek indítási hibái általában három különálló dolog egyikét érintik: a képességet, az alagúteszközt és a protokoll kernel-támogatását. Mindhárom egyszerre való megadása működik, és azt is eléri, hogy a következő hiba ne legyen beazonosítható. Egy minimális compose-töredék megadja a képességet, és kifejezetten átadja az eszközcsomópontot:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

Olvassa el az image saját dokumentációját arról, mely sysctl-ekre van szüksége, mert a konténerben lévő sysctl további jogosultságot vagy hosztszintű beállítást igényelhet. Ahol az image csak felhasználói tér módot támogat, ott egyáltalán nincs szükség eszközre, és a képességlista ennek megfelelően zsugorodik.

A szűk műveletet adja meg, ne a módot

A kiemelt mód minden képességet átad, és egyidejűleg kiszélesíti az eszközhozzáférést, így elrejti, melyik hiányzott a három előfeltétel közül. Azt is eléri, hogy a konténer hibaformái megkülönböztethetetlenek legyenek a hoszt változásaitól. Inkább adjon meg kifejezett listát, még ha hosszabb is leírni.

A root nélküli és felhasználói névtérben történő telepítések megváltoztatják, mit jelent a képesség a gyakorlatban, mert a folyamat csak leképezett névtéren belül birtokolhatja. A képességlista rootos példából root nélküli futtatókörnyezetbe másolása és ugyanazon hatáskör elvárása bevett módja egy délután elvesztésének.

A titkok külön döntéshez tartoznak. A NET_ADMIN birtoklása semmit sem mond arról, milyen társidentitást mutat a kliens, milyen hitelesítő adatokat tölt be, vagy hogyan forgatják azokat. A hálózati adminisztráció nem ad bizalmat.

Ellenőrizze a változtatást, és jegyezze fel, miért létezik a megadás

Az alagút hibakeresése előtt erősítse meg, mit kapott valójában a konténer. Az alábbi vizsgálat jelenti a hozzáadott képességeket és a hálózati módot, majd megmutatja, hogyan néz ki az interfészlista belülről:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

Ha a képesség jelen van, és az interfészlista továbbra is üres, a kliens még azelőtt meghiúsult, hogy bármit létrehozhatott volna, és a következő hely, ahol érdemes nézni, a konténer naplói. Ha az alagút létezik, de a forgalom nem folyik, a konténeren belüli útvonaltábla válaszol a következő kérdésre.

Tesztelje a lebontási útvonalat is, mert a tűzfalszabályokat író kliens hátrahagyhatja azokat. Állítsa le a konténert, és ellenőrizze újra a hoszt szabálykészletét, ha hoszthálózatot használ. Az a megadás, amelyre csak két másodpercig van szükség indításkor, ne legyen a compose-fájlban állandó követelményként leírva anélkül, hogy egy megjegyzés ezt megmagyarázná.

Írja oda az okot minden képesség mellé: melyik műveletnek kellett, és mi hibázik nélküle. Ez a megjegyzés túléli az image-frissítéseket, és ez a különbség egy átvizsgált jogosultságlista és egy másolással növekedett lista között.

Kapcsolódó cikkek