NET_ADMIN sa isang container ng VPN: ano at saan ito makakapagbago

NET_ADMIN ang kakayahan ng Linux na nagpapahintulot sa isang proseso na magsagawa ng administrasyon ng network, at sa isang container ginagawa nito nang eksakto iyon sa loob ng namespace ng network kung saan tumatakbo ang proseso. Hindi ito lisensya para magbukas ng socket, at hindi ito kapalit ng isang device o ruta. Ang kawili-wiling tanong ay hindi kailanman kung ipinagkaloob ang kakayahan, kundi kung aling namespace ang tumatanggap ng pagbabago.

Ano ang saklaw ng kakayahan

Sa loob ng sarili nitong namespace, ang isang prosesong may NET_ADMIN ay maaaring magtaas at magbaba ng mga interface, magtalaga ng mga address, magdagdag at mag-alis ng mga ruta at magsulat ng mga tuntunin ng firewall, na siyang pangkat ng mga operasyon na tinipon ng capabilities(7) sa ilalim ng kakayahang ito. Maaari rin nitong iayos ang mga setting sa antas ng interface na kumokontrol kung paano pinipila at sinasala ng kernel ang trapiko. Ang isang kliyente ng VPN ay karaniwang nangangailangan ng ilan sa mga ito sa pagsisimula at wala nang iba pagkatapos. Kaya karamihan ng mga image ay humihingi ng mas malawak na saklaw kaysa ginagamit.

Ang mga operasyon sa labas ng namespace na iyon ay hindi saklaw, at ang mga katabing pribilehiyo ay hiwalay. Ang pagbasa at pagsulat ng mga raw packet ay kabilang sa NET_RAW, at ang paglikha ng isang tun device ay nangangailangan ng kakayahan at pag-access sa node ng device kapwa. Ang isang prosesong walang device ay nakakakuha ng error sa pahintulot na mukhang problema sa network at hindi naman.

Ang namespace ang nagtatakda ng saklaw ng pinsala

Ang isang container sa sarili nitong bridge network ay umaabot sa sarili nitong loopback, sarili nitong mga interface at sarili nitong routing table. Ang pagbibigay ng NET_ADMIN doon ay nagpapahintulot sa kliyente ng VPN na bumuo ng tunnel nang hindi hinahawakan ang mga desisyon sa routing ng host, na siyang kaayusan na ipinapalagay ng karamihan ng mga image ng container.

Ilipat ang container na iyon sa host networking at ang parehong pagbibigay ay nag-e-edit na ngayon ng mga ruta ng host at firewall ng host, dahil wala nang natitirang hiwalay na namespace. Ang kliyenteng dapat mamahala ng isang tunnel ay maaari na ngayong i-redirect ang trapiko ng buong makina, at ang isang pagkakamali sa script nito sa pagtanggal ay nag-iiwan sa host ng mga tuntuning walang sinumang nagsulat. Walang nagbago sa mismong kakayahan; ang konteksto ang nagbago. Iyon ang dahilan kung bakit ang parehong file ng compose ay kumikilos nang iba sa dalawang host.

Tatlong paunang kundisyon na pinagsama sa isa

Ang mga pagkabigo sa pagsisimula sa mga container ng VPN ay karaniwang may kinalaman sa isa sa tatlong hiwalay na bagay: ang kakayahan, ang tunnel device at ang suporta ng kernel para sa protocol. Ang pagbibigay ng tatlo nang sabay ay gumagana, at ginagawa rin nitong hindi maipagkakabit ang susunod na pagkabigo. Ang isang minimal na piraso ng compose ay nagbibigay ng kakayahan at tahasang ipinapasa ang node ng device:

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

Basahin ang dokumentasyon ng image mismo para sa kung aling sysctl ang kailangan nito, dahil ang isang sysctl sa loob ng container ay maaaring mangailangan ng karagdagang pribilehiyo o setting sa antas ng host. Kung saan sinusuportahan lamang ng image ang user-space mode, wala nang kailangang device at lumiliit ang listahan ng mga kakayahan ayon dito.

Ibibigay ang makitid na operasyon, hindi ang mode

Ang privileged mode ay nag-aabot ng bawat kakayahan at pinalalawak ang pag-access sa device nang sabay, kaya itinatago nito kung alin sa tatlong paunang kundisyon ang kulang. Ginagawa rin nitong hindi matukoy ang mga paraan ng pagkabigo ng container mula sa mga pagbabago sa host. Mas mainam ang tahasang listahan kahit mas mahaba itong isulat.

Ang mga deployment na rootless at sa mga namespace ng user ay nagbabago kung ano ang ibig sabihin ng kakayahan sa pagsasanay, dahil maaari lamang itong hawakan ng proseso sa loob ng isang naka-map na namespace. Ang pagkopya ng listahan ng mga kakayahan mula sa isang rootful na halimbawa patungo sa isang rootless na runtime at pag-asa ng parehong saklaw ay isang karaniwang paraan ng pagkawala ng isang hapon.

Ang mga lihim ay kabilang sa isang hiwalay na desisyon. Ang pagkakaroon ng NET_ADMIN ay walang sinasabi tungkol sa kung anong pagkakakilanlan ng peer ang ipinapakita ng kliyente, anong mga kredensyal ang ikinakarga nito o paano iyon iniikot. Ang administrasyon ng network ay hindi nagbibigay ng tiwala.

I-verify ang pagbabago at itala kung bakit may pagbibigay

Tiyakin kung ano talaga ang natanggap ng container bago i-debug ang tunnel. Ang inspeksyon sa ibaba ay nag-uulat ng mga idinagdag na kakayahan at ng mode ng network, pagkatapos ay ipinapakita kung ano ang hitsura ng listahan ng interface mula sa loob:

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

Kung naroroon ang kakayahan at walang laman pa rin ang listahan ng interface, nabigo ang kliyente bago pa ito makagawa ng anuman, at ang mga log ng container ang susunod na lugar na titingnan. Kung may tunnel ngunit hindi dumadaloy ang trapiko, sinasagot ng routing table sa loob ng container ang susunod na tanong.

Subukan din ang landas ng pagtanggal, dahil ang isang kliyenteng nagsusulat ng mga tuntunin ng firewall ay maaaring mag-iwan ng mga iyon. Ihinto ang container at muling suriin ang set ng mga tuntunin ng host kung gumagamit ng host networking. Ang isang pagbibigay na kailangan lamang ng dalawang segundo sa pagsisimula ay hindi dapat ilarawan sa file ng compose bilang permanenteng pangangailangan nang walang tala na nagpapaliwanag nito.

Isulat ang dahilan sa tabi ng bawat kakayahan: aling operasyon ang nangailangan nito at ano ang nabibigo kung wala ito. Ang talang iyon ay nananatili pagkatapos ng mga update ng image, at iyon ang pagkakaiba ng isang nasuri na listahan ng pribilehiyo at ng isang pinalaki ng kopya at paste.