NET_ADMIN yn in VPN-kontener: wat it feroarje kin en wêr

De mooglikheid lit feroarings fan ynterfaces, rûtes en firewall ta binnen ien netwurknammeromte. Mei hostnetwurk is dy romte de eigen stapel fan 'e host.

NET_ADMIN is de Linux-mooglikheid dy't in proses netwurkbehear útfierje lit, en yn in kontener docht it krekt dat binnen de netwurknammromte wêryn't it proses draait. It is gjin lisinsje om in socket te iepenjen en gjin ferfanging foar in apparaat of in rûte. De nijsgjirrige fraach is nea oft de mooglikheid jûn is, mar hokker nammromte de feroaring krijt.

Wat de mooglikheid beslacht

Binnen syn nammromte kin in proses mei NET_ADMIN ynterfaces omheech en omleech bringe, adressen tawize, rûtes tafoegje en fuortsmite en firewallregels skriuwe, wat de groep bewurkingen is dy't capabilities(7) ûnder dizze mooglikheid sammelt. It kin ek ynstellingen op ynterfacenivo oanpasse dy't regelje hoe't de kearn ferkear yn 'e rige set en filteret. In VPN-klant hat by it opstarten meast in pear dêrfan nedich en dêrnei neat mear. Dêrom freegje de measte imagens om mear berik as se brûke.

Bewurkingen bûten dy nammromte wurde net beslchte, en neistlizzende foarrjochten binne apart. Lêzen en skriuwen fan rauwe pakketten heart by NET_RAW, en it meitsjen fan in tun-apparaat freget sawol de mooglikheid as tagong ta it apparaatknooppunt. In proses sûnder it apparaat krijt in tastimmingsflater dy't op in netwurkprobleem liket en dat net is.

De nammromte bepaalt de skea

In kontener op syn eigen brêgenetwurk berikt syn eigen loopback, syn eigen ynterfaces en syn eigen rûtetabel. It jaan fan NET_ADMIN dêr lit de VPN-klant in tunnel bouwe sûnder de rûtebeslissingen fan 'e host oan te reitsjen, wat de opstelling is dy't de measte kontenerimagins oannimme.

Skeakelje dy kontener oer nei hostnetwurk en deselde jefte bewurket no de rûtes fan 'e host en de firewall fan 'e host, om't der gjin aparte nammromte mear oer is. De klant dy't ien tunnel beheare moast, kin dan it ferkear fan 'e hiele masine omliede, en in flater yn syn ôfbrekskript lit de host regels efter dy't nimmen skreau. Oan 'e mooglikheid sels feroare neat; de kontekst feroare. Dêrom gedraacht deselde compose-triem him oars op twa hosts.

Trije betingsten dy't yn ien ferranne wurde

Opstartflaters yn VPN-konteners belûke meast ien fan trije aparte dingen: de mooglikheid, it tunnelapparaat en kearnstipe foar it protokol. Alle trije tagelyk jaan wurket, en it makket de folgjende flater ek net mear ta te skriuwen. In minimaal compose-fragmint jout de mooglikheid en jout it apparaatknooppunt eksplisyt troch:

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

Lês de eigen dokumintaasje fan it image foar hokker sysctls it nedich hat, om't in sysctl yn in kontener in ekstra foarrjocht of in ynstelling op hostnivo freegje kin. Wêr't it image allinnich de brûkersromtemodus stipet, is hielendal gjin apparaat nedich en krimpt de list fan mooglikheden dêrneffens.

Jou de smelle bewurking, net de modus

De foarrjochtmode jout alle mooglikheden oer en ferbreedt tagelyk de apparaatstagong, dat it ferberget hokker fan 'e trije betingsten miste. It makket ek de flatermodi fan 'e kontener net te ûnderskieden fan hostferoarings. Ferken de foarkar oan in eksplisite list, sels as dy langer is om te skriuwen.

Rootless- en brûkersnammromte-ynsetten feroarje wat in mooglikheid yn 'e praktyk betsjut, om't it proses it allinnich binnen in mapte nammromte hâlde kin. In list fan mooglikheden fan in rootful foarbyld nei in rootless útfieromjouwing kopiearje en itselde berik ferwachtsje is in gewoane manier om in middei te ferliezen.

Geheimen hearre by in aparte beslissing. NET_ADMIN hâlde seit neat oer hokker peer-identiteit de klant presintearret, hokker bewiisstikken it ladt of hoe't dy rotearre wurde. Netwurkbehear leveret gjin fertrouwen.

Kontrolearje de feroaring en skriuw op wêrom't de jefte bestiet

Befêstigje wat de kontener wier krigen hat foardat jo de tunnel debugge. De ynspeksje hjirûnder rapportearret de tafoege mooglikheden en de netwurkmode, en lit dan sjen hoe't de ynterfacelist fan binnen útsjocht:

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

As de mooglikheid oanwêzich is en de ynterfacelist noch altyd leech is, is de klant mislearre foardat er eat meitsje koe, en de kontenerlogboeken binne it folgjende plak om te sjen. As de tunnel bestiet mar it ferkear streamt net, beantwurdet de rûtetabel binnen de kontener de folgjende fraach.

Test ek it ôfbrekpaad, om't in klant dy't firewallregels skriuwt se efterlitte kin. Stop de kontener en kontrolearje de regelset fan 'e host opnij as hostnetwurk brûkt wurdt. In jefte dy't by it opstarten mar twa sekonden nedich is, moat yn 'e compose-triem net as in permaninte eask beskreaun wurde sûnder in notysje dy't dat ferklearret.

Skriuw de reden njonken elke mooglikheid: hokker bewurking it nedich hie en wat sûnder it mislearret. Dat notysje oerlibbet image-updates, en it is it ferskil tusken in neisjoen foarrjochtenlist en ien dy't troch kopiearjen en plakken groeid is.

Relatearre artikelen