NET_ADMIN en VPN-kontenero: kion ĝi povas ŝanĝi kaj kie

La kapablo permesas ŝanĝojn de interfacoj, itineroj kaj fajroŝirmilo ene de unu reta nomspaco. Ĉe gastiga reto tiu nomspaco estas la propra stako de la gastiganto.

NET_ADMIN estas la Linuksa kapablo, kiu ebligas al procezo fari retan administradon, kaj en kontenero ĝi faras ĝuste tion ene de tiu reta nomspaco, en kiu la procezo funkcias. Ĝi ne estas permesilo malfermi ingon, kaj ĝi ne estas anstataŭaĵo por aparato aŭ itinero. La interesa demando neniam estas, ĉu la kapablo estas donita, sed kiu nomspaco ricevas la ŝanĝon.

Kion la kapablo kovras

Ene de sia nomspaco procezo tenanta NET_ADMIN povas suprenigi kaj subenigi interfacojn, atribui adresojn, aldoni kaj forigi itinerojn kaj skribi fajroŝirmilajn regulojn, kio estas la grupo de operacioj, kiun capabilities(7) kolektas sub ĉi tiu kapablo. Ĝi ankaŭ povas agordi nivelinterfacajn agordojn, kiuj regas kiel la kerno vicigas kaj filtras trafikon. VPN-kliento kutime bezonas kelkajn el ili ĉe lanĉo kaj nenion alian poste. Tial plej multaj bildoj petas pli grandan atingon ol ili uzas.

Operacioj ekster tiu nomspaco ne estas kovritaj, kaj apudaj privilegioj estas apartaj. Legado kaj skribado de krudaj pakaĵoj apartenas al NET_RAW, kaj kreado de tun-aparato bezonas kaj la kapablon kaj aliron al la aparata nodo. Procezo sen la aparato ricevas permeseraron, kiu aspektas kiel reta problemo kaj ne estas.

La nomspaco decidas la eksplodradiuson

Kontenero sur sia propra ponta reto atingas sian propran loopback, siajn proprajn interfacojn kaj sian propran itinertabelon. Doni NET_ADMIN tie ebligas al la VPN-kliento konstrui tunelon sen tuŝi la itinerajn decidojn de la gastiganto, kio estas la aranĝo, kiun plej multaj konteneraj bildoj supozas.

Ŝaltu tiun konteneron al gastiga reto kaj la sama dono nun redaktas la itinerojn de la gastiganto kaj la fajroŝirmilon de la gastiganto, ĉar restas neniu aparta nomspaco. La kliento, kiu devis administri unu tunelon, tiam povas alidirekti trafikon por la tuta maŝino, kaj eraro en ĝia malmunt-skripto lasas al la gastiganto regulojn, kiujn neniu skribis. Nenio en la kapablo mem ŝanĝiĝis; la kunteksto ŝanĝiĝis. Tial la sama compose-dosiero kondutas malsame sur du gastigantoj.

Tri antaŭkondiĉoj kunfanditaj en unu

Lanĉaj malsukcesoj en VPN-konteneroj kutime temas pri unu el tri apartaj aferoj: la kapablo, la tunela aparato kaj kernsubteno por la protokolo. Doni ĉiujn tri samtempe funkcias, kaj ĝi ankaŭ igas la sekvan malsukceson neatribuebla. Minimuma compose-fragmento donas la kapablon kaj pasigas la aparatan nodon eksplicite:

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

Legu la propran dokumentaron de la bildo pri tio, kiujn sysctl ĝi bezonas, ĉar sysctl en kontenero povas postuli plian privilegion aŭ agordon je gastiga nivelo. Kie la bildo subtenas nur uzantspacan reĝimon, aparato tute ne necesas kaj la kapablisto malgrandiĝas laŭe.

Donu la mallarĝan operacion, ne la reĝimon

Privilegia reĝimo transdonas ĉiun kapablon kaj samtempe larĝigas aparatan aliron, do ĝi kaŝas, kiu el la tri antaŭkondiĉoj mankis. Ĝi ankaŭ igas la malsukcesmanierojn de la kontenero nedistingeblaj de ŝanĝoj de la gastiganto. Preferu eksplicitan liston eĉ kiam ĝi estas pli longa skribi.

Senradikaj kaj uzantnomspacaj deplojoj ŝanĝas, kion kapablo signifas praktike, ĉar la procezo povas teni ĝin nur ene de mapita nomspaco. Kopii kapabliston el senradika ekzemplo al senradika rulmedio kaj atendi la saman atingon estas komuna maniero perdi posttagmezon.

Sekretoj apartenas al aparta decido. Teni NET_ADMIN diras nenion pri tio, kiun kunulan identecon la kliento prezentas, kiujn legitimilojn ĝi ŝargas aŭ kiel tiuj rotacias. Reta administrado ne donas fidon.

Kontrolu la ŝanĝon kaj registru, kial la dono ekzistas

Konfirmu, kion la kontenero efektive ricevis, antaŭ ol sencimigi la tunelon. La suba inspekto raportas la aldonitajn kapablojn kaj la retan reĝimon, poste montras kiel la interfaclisto aspektas de interne:

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

Se la kapablo ĉeestas kaj la interfaclisto ankoraŭ malplenas, la kliento malsukcesis antaŭ ol ĝi povis krei ion ajn, kaj la konteneraj protokoloj estas la sekva loko por rigardi. Se la tunelo ekzistas sed trafiko ne fluas, la itinertabelo ene de la kontenero respondas la sekvan demandon.

Testu ankaŭ la malmuntan vojon, ĉar kliento, kiu skribas fajroŝirmilajn regulojn, povas lasi ilin malantaŭe. Haltigu la konteneron kaj rekontrolu la regulan aron de la gastiganto se gastiga reto estas uzata. Dono bezonata nur dum du sekundoj ĉe lanĉo ne priskribiĝu en la compose-dosiero kiel permanenta postulo sen noto klariganta tion.

Skribu la kialon apud ĉiu kapablo: kiu operacio bezonis ĝin kaj kio malsukcesas sen ĝi. Tiu noto postvivas bildajn ĝisdatigojn, kaj ĝi estas la diferenco inter reviziita privilegiolisto kaj unu kreskinta per kopio kaj algluo.

Rilataj artikoloj