Kial privilegia reĝimo estas pli vasta ol VPN bezonas

La ujo ne volis malfermi sian tunelon, do la privilegia flago eniris, kaj nun ĝi funkcias. Tiu sinsekvo pruvis nur, ke mankis almenaŭ unu permeso, kaj ĝi diras nenion pri tio, kiu. Privilegia reĝimo donas aron da kapabloj kaj aliron al aparatoj multe pli vastan ol bezonas tunela interfaco.

Kion la flago efektive ŝanĝas

Privilegia ujo ricevas vastajn kapablojn kaj aliron al aparatoj de la gastiganto, kio estas multe pli granda permeso ol postulas la reta vojo. La precizan aron dokumentas la plenummedio kaj ne fiksas tradicio, kaj la Docker-dokumentaro pri ruligado de ujoj priskribas la disponeblajn privilegiajn opciojn. Unufoja legado sufiĉas por vidi, ke tunelado estas malgranda parto de la tuto.

Du pli mallarĝaj postuloj kovras la plej multajn VPN-ujojn. Konfiguri interfacon postulas la kapablon administri reton, kaj malfermi la tunelan aparaton postulas aliron al ĝuste tiu aparata nodo. Tiuj estas apartaj permesoj, kaj eĉ ambaŭ kune estas pli mallarĝaj ol la ĝenerala opcio. La resto de la privilegia aro havas nenion rilatan al la tunelo. Ĝi ekzistas por laborŝarĝoj, kiuj vere bezonas aliron je gastiganta nivelo, kaj VPN-ujo kutime ne estas unu el ili.

Parigu ĉiun eraron kun unu antaŭkondiĉo

La erarmesaĝo diras al vi, kiu antaŭkondiĉo mankas, se vi legas ĝin antaŭ ol silentigi ĝin. Mesaĝo pri aparata nodo nomas la aparaton, mesaĝo pri nepermesita operacio nomas kapablon, kaj mesaĝo pri modulo aŭ sysctl nomas kernan subtenon. Ĉiu el ili havas malsaman riparon, kaj nur unu el ili estas kapablo.

Mankanta agorda dosiero restas mankanta post kiam ĉiu kapablo estas donita, kial privilegia reĝimo foje ŝanĝas absolute nenion. La ujo startas, la tunelo ankoraŭ malsukcesas, kaj la reala eraro neniam temis pri permesoj. Kerna subteno estas la tria kazo kaj la plej facile mislegata. Modulo, kiu ne estas ŝargita sur la gastiganto, ne povas esti ŝargita el malprivilegia ujo, kaj doni pli da kapabloj ene de la ujo ne ŝanĝas la staton de la gastiganto.

Kontrolu la postulon, ne la simptomon

Komencu de la minimuma alvoko, kiun la bildo dokumentas, ruligu ĝin, kaj konservu la precizan fiaskotekston. Poste aldonu unu permeson samtempe kaj notu, kiu aldono ŝanĝis la rezulton.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Ujo, kiu vidas la aparaton kaj tenas la kapablon sed tamen malsukcesas, diras al vi, ke la problemo estas aliloke. Tio estas utila rezulto, kaj privilegia reĝimo kaŝus ĝin.

Kontrolu ankaŭ la aparatajn permesojn sur la gastiganto, ĉar ĝuste donita aparata nodo kun malĝusta grupiga posedo produktas la saman eraron kiel mankanta permeso.

Notu la plej mallarĝan permeson, kiu funkcias

Notu ĉiun aparaton kaj kapablon, kiujn la deplojo bezonas, kune kun la eraro, kiu pravigis ĝin. Tiu registro estas tio, kio ebligas al la sekva persono sekure forigi ion, kaj ĝi estas tio, kion revizoro petos, kiam ujo estos raportita kiel privilegia.

Revizuu ankaŭ la ĉirkaŭan kuntekston, ĉar gastiganta reto, gastigantaj muntadoj kaj plenummediaj opcioj povas ĉiu vastigi la efikon de permeso. Izolita laboratoria alvoko, kiu kombinas ĉiujn, ne estas produktada agordo, kiel ajn bone ĝi funkciis. Testu la aplikaĵon, ĝian DNS-konduton kaj tunelan fiaskon antaŭ ol nomi la deplojon finita. Permeso krei interfacon ne estas elira politiko, kaj ujo, kiu povas perfekte tuneli, ankoraŭ enkursigas ĉion, kion la aplikaĵo sendas.