NET_ADMIN dalam kontena VPN: apa dan di mana ia boleh mengubah

NET_ADMIN ialah keupayaan Linux yang membenarkan proses melakukan pentadbiran rangkaian, dan dalam kontena ia melakukan tepat itu di dalam ruang nama rangkaian tempat proses berjalan. Ia bukan lesen untuk membuka soket, dan bukan pengganti peranti atau laluan. Soalan menarik bukanlah sama ada keupayaan itu diberikan, tetapi ruang nama mana yang menerima perubahan.

Apa yang diliputi keupayaan

Di dalam ruang namanya, proses yang memegang NET_ADMIN boleh menaik dan menurunkan antara muka, menetapkan alamat, menambah dan membuang laluan serta menulis peraturan firewall, iaitu kumpulan operasi yang dikumpulkan capabilities(7) di bawah keupayaan ini. Ia juga boleh melaras tetapan peringkat antara muka yang mengawal cara kernel beratur dan menapis trafik. Klien VPN biasanya memerlukan beberapa daripadanya semasa permulaan dan tiada apa-apa lagi selepas itu. Itulah sebabnya kebanyakan imej meminta jangkauan lebih besar daripada yang digunakan.

Operasi di luar ruang nama itu tidak diliputi, dan keistimewaan bersebelahan adalah berasingan. Membaca dan menulis paket mentah tergolong dalam NET_RAW, dan mencipta peranti tun memerlukan kedua-dua keupayaan dan akses kepada nod peranti. Proses tanpa peranti mendapat ralat kebenaran yang kelihatan seperti masalah rangkaian tetapi bukan.

Ruang nama menentukan jejari kerosakan

Kontena pada rangkaian jambatannya sendiri mencapai loopback sendiri, antara muka sendiri dan jadual laluan sendiri. Memberi NET_ADMIN di situ membolehkan klien VPN membina terowong tanpa menyentuh keputusan laluan hos, iaitu susunan yang diandaikan oleh kebanyakan imej kontena.

Tukar kontena itu kepada rangkaian hos dan pemberian yang sama kini menyunting laluan hos dan firewall hos, kerana tiada ruang nama berasingan yang tinggal. Klien yang sepatutnya mengurus satu terowong kemudian boleh mengubah hala trafik seluruh mesin, dan kesilapan dalam skrip pembongkarannya meninggalkan peraturan pada hos yang tidak ditulis oleh sesiapa. Tiada apa yang berubah pada keupayaan itu sendiri; konteksnya berubah. Itulah sebabnya fail compose yang sama berkelakuan berbeza pada dua hos.

Tiga prasyarat yang dilebur menjadi satu

Kegagalan permulaan dalam kontena VPN biasanya melibatkan salah satu daripada tiga perkara berasingan: keupayaan, peranti terowong dan sokongan kernel untuk protokol. Memberi ketiga-tiganya sekali gus berkesan, dan ia juga menjadikan kegagalan seterusnya tidak dapat dikaitkan. Serpihan compose minimum memberikan keupayaan dan menyalurkan nod peranti secara eksplisit:

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

Baca dokumentasi imej itu sendiri untuk mengetahui sysctl mana yang diperlukan, kerana sysctl dalam kontena mungkin memerlukan keistimewaan tambahan atau tetapan peringkat hos. Di tempat imej hanya menyokong mod ruang pengguna, peranti tidak diperlukan sama sekali dan senarai keupayaan mengecil mengikutnya.

Berikan operasi sempit, bukan modnya

Mod istimewa menyerahkan setiap keupayaan dan meluaskan akses peranti pada masa yang sama, jadi ia menyembunyikan prasyarat mana antara ketiga-tiganya yang hilang. Ia juga menjadikan cara kontena gagal tidak dapat dibezakan daripada perubahan hos. Utamakan senarai eksplisit walaupun ia lebih panjang untuk ditulis.

Penggunaan tanpa root dan ruang nama pengguna mengubah maksud keupayaan dalam amalan, kerana proses mungkin hanya memegangnya di dalam ruang nama yang dipetakan. Menyalin senarai keupayaan daripada contoh rootful ke runtime tanpa root dan menjangkakan jangkauan yang sama ialah cara biasa untuk kehilangan satu petang.

Rahsia tergolong dalam keputusan berasingan. Memegang NET_ADMIN tidak menyatakan apa-apa tentang identiti rakan sebaya yang dikemukakan klien, kelayakan yang dimuatkannya atau cara ia diputar. Pentadbiran rangkaian tidak menyediakan kepercayaan.

Sahkan perubahan dan catat mengapa pemberian itu wujud

Pastikan apa yang sebenarnya diterima kontena sebelum anda menyahpepijat terowong. Pemeriksaan di bawah melaporkan keupayaan yang ditambah dan mod rangkaian, kemudian menunjukkan bagaimana senarai antara muka kelihatan dari dalam:

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

Jika keupayaan ada dan senarai antara muka masih kosong, klien gagal sebelum dapat mencipta apa-apa, dan log kontena ialah tempat seterusnya untuk dilihat. Jika terowong wujud tetapi trafik tidak mengalir, jadual laluan di dalam kontena menjawab soalan seterusnya.

Uji juga laluan pembongkaran, kerana klien yang menulis peraturan firewall boleh meninggalkannya. Hentikan kontena dan semak semula set peraturan hos jika rangkaian hos digunakan. Pemberian yang hanya diperlukan dua saat semasa permulaan tidak sepatutnya diterangkan dalam fail compose sebagai keperluan kekal tanpa nota yang menjelaskannya.

Tulis sebabnya di sebelah setiap keupayaan: operasi mana yang memerlukannya dan apa yang gagal tanpanya. Nota itu kekal melalui kemas kini imej, dan itulah perbezaan antara senarai keistimewaan yang disemak dan senarai yang membesar melalui salin dan tampal.