NET_ADMIN ass d'Linux-Capability, déi engem Prozess erlaabt, Netzwierkadministratioun ze maachen, an an engem Container mécht se genee dat bannent deem Netzwierk-Namensraum, an deem de Prozess leeft. Et ass keng Lizenz fir e Socket opzemaachen, an et ass keen Ersatz fir en Apparat oder eng Route. Déi interessant Fro ass ni, ob d'Capability gëtt, mä wéi en Namensraum d'Ännerung kritt.

Wat d'Capability deckt

Bannent sengem Namensraum kann e Prozess mat NET_ADMIN Interface erop- an erofsetzen, Adressen zouweisen, Routen derbäisetzen an ewechhuelen a Firewallregele schreiwen, dat ass d'Grupp vun Operatiounen, déi capabilities(7) ënner dëser Capability sammelt. Et kann och Astellungen op Interface-Niveau upassen, déi kontrolléieren, wéi de Kernel Trafic an d'Schlaang setzt a filtert. E VPN-Client brauch typesch e puer dovun beim Start an duerno näischt méi. Dofir froen déi meescht Images méi Reach un, wéi se benotzen.

Operatiounen ausserhalb vun deem Namensraum si net ofgedeckt, an Nopeschprivilegien si getrennt. Liesen a Schreiwe vu rohe Paketen gehéiert zu NET_RAW, an d'Erstelle vun engem tun-Apparat brauch souwuel d'Capability wéi och Zougang zum Apparatknuet. E Prozess ouni den Apparat kritt e Permissiounsfehler, dee wéi e Netzwierkproblem ausgesäit an keen ass.

Den Namensraum bestëmmt de Radius

E Container op sengem eegene Bridge-Netzwierk erreecht säin eegene Loopback, seng eegen Interface an seng eegen Routingtabell. Wann een do NET_ADMIN gëtt, kann de VPN-Client en Tunnel bauen, ouni dem Host seng Routingentscheedungen ze beréieren, wat d'Arrangement ass, dat déi meescht Container-Images unhuelen.

Wiesselt dee Container op Host-Netzwierk, an déiselwecht Verginn ännert elo dem Host seng Routen an dem Host seng Firewall, well keen getrennten Namensraum méi iwwereg ass. De Client, deen een eenzegen Tunnel sollt geréieren, kann dann den Trafic vun der ganzer Maschinn ëmleeden, an e Feeler a sengem Ofbrochskript hannerléisst dem Host Reegelen, déi keen geschriwwen huet. An der Capability selwer huet sech näischt geännert; de Kontext huet sech geännert. Dofir behält sech déiselwecht Compose-Datei op zwee Hosten anescht.

Dräi Viraussetzungen, déi zu enger verschmëlzen

Startfeeler a VPN-Containeren betreffen normalerweis eng vun dräi getrennten Saachen: d'Capability, den Tunnelapparat an d'Kernelënnergrëtzung fir de Protokoll. All dräi op eemol ze ginn funktionéiert, an et mécht de nächste Feeler onzouuerdnen. E minimalen Compose-Fragment gëtt d'Capability a gëtt den Apparatknuet explizit weider:

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

Liest an der Dokumentatioun vum Image no, wéi eng sysctls et brauch, well en sysctl an engem Container en zousätzleche Privileg oder eng Astellung op Host-Niveau erfuerdere kann. Wou d'Image nëmmen de Userspace-Modus ënnerstëtzt, ass iwwerhaapt keen Apparat néideg an d'Lëscht vun de Capabilities schrumpft entspriechend.

Gitt déi enk Operatioun, net de Modus

De privilegéierte Modus iwwerléisst all Capability an erweidert gläichzäiteg den Apparatzougang, sou datt en verstoppt, wéi eng vun den dräi Viraussetzunge gefeelt huet. En mécht och d'Feelermuster vum Container vun Host-Ännerungen onënnerscheedbar. Bevirzugt eng explizit Lëscht, och wann se méi laang ze schreiwen ass.

Rootless- an User-Namensraum-Deployementer änneren, wat eng Capability an der Praxis bedeit, well de Prozess se just bannent engem gemappten Namensraum halen kann. Eng Capabilitylëscht vun engem rootful Beispill an eng rootless Runtime ze kopéieren an dee selwechte Reach ze erwaarden ass e gewéinleche Wee, en Nomëtteg ze verléieren.

Geheimnisser gehéieren zu enger separater Entscheedung. NET_ADMIN ze halen seet näischt doriwwer, wéi eng Peer-Identitéit de Client presentéiert, wéi eng Authentifikatiounsdonnéeën en lued oder wéi déi rotéiert ginn. Netzwierkadministratioun liwwert keen Vertrauen.

Verifizéiert d'Ännerung a notéiert, firwat d'Verginn existéiert

Bestätegt, wat de Container tatsächlech kritt huet, ier Dir den Tunnel debugt. Déi ënnescht Inspektioun mellt déi bäigefüügte Capabilities an de Netzwierkmodus an weist dann, wéi d'Interface-Lëscht vun banne ausgesäit:

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

Wann d'Capability do ass an d'Interface-Lëscht nach ëmmer eidel ass, ass de Client gescheitert, ier en eppes konnt uleeën, an d'Container-Logs sinn déi nächst Plaz fir nozekucken. Wann den Tunnel existéiert, awer den Trafic net fléisst, äntwert d'Routingtabell am Container op déi nächst Fro.

Test och den Ofbrochwee, well e Client, dee Firewallregele schreift, se ka hannerloossen. Stoppt de Container a kontrolléiert dem Host säi Regelset nach eng Kéier, wann Host-Netzwierk benotzt gëtt. Eng Verginn, déi just zwou Sekonnen beim Start néideg ass, sollt an der Compose-Datei net als permanent Ufuerderung beschriwwe ginn, ouni eng Notiz déi dat erkläert.

Schreift de Grond niewent all Capability: wéi eng Operatioun se gebraucht huet a wat ouni se feelt. Déi Notiz iwwerlieft Image-Updates, an et ass den Ënnerscheed tëscht enger iwwerpréifter Privilegielëscht an enger, déi duerch Kopéieren a Pechë gewuess ass.

Ähnlech Artikelen