Kiujn Linux-kapablojn bezonas via VPN-procezo?
Interfaca agordo, itineroj, aparata aliro kaj ordinaraj ingoj estas apartaj privilegioj. Nomu la operacion, kiu malsukcesis, antaŭ ol doni CAP_NET_ADMIN.
VPN-demono bezonas privilegiajn retajn operaciojn, kvankam ordinaraj programoj malfermas elirajn ingojn tute sen ajna privilegio. En tiu manko komenciĝas la plej multaj eraroj pri kapabloj: iu vidas permeseraron, donas la tutan aron, kaj la servo funkcias pro kialoj, kiujn poste neniu povas klarigi. La sekva trairo komenciĝas ĉe la malsukcesinta operacio, mapas ĝin al unu aŭtoritato, kaj poste kontrolas la kuntekston, en kiu la procezo efektive ruliĝas. Ruli kiel senlima root estas valida respondo por kelkaj enkondukoj, sed ĝi devus esti decido, ne defaŭlto.
Komencu ĉe la malsukcesinta operacio
Legu la eraron antaŭ ol legi lernilon. «Operacio ne permesita» ĉe interfaca ŝanĝo, rifuzo malfermi aparatan nodon kaj malsukcesa bind sur malalta pordo estas tri malsamaj problemoj kun tri malsamaj donaĵoj. Se la procezo startas kaj malsukcesas nur ĉe la unua itinera ŝanĝo, tio ankaŭ diras, ke la interfaca kreado jam sukcesis, kio konsiderinde mallarĝigas la respondon.
Reproduktu la malsukceson kun la servo haltigita, poste startu ĝin en la antaŭplano sub la sama uzanto, se la efektivigo tion permesas. Eraro, kiun vi povas vidi, estas pli bona ol loglinio, kiun vi devas diveni, kaj ĝi evidentigas la diferencon inter kapabla problemo kaj rifuzo de SELinux aŭ AppArmor.
Mapu ĉiun operacion al unu aŭtoritato
La tabelo estas komenca mapo, ne anstataŭaĵo por la dokumentaro de la efektivigo:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
La du vicoj en tiu tabelo estas tiuj, kiujn homoj konfuzas. Malfermi /dev/net/tun estas demando pri dosieraj permesoj; peti la kernon agordi tion, kion vi malfermis, estas demando pri kapabloj. Doni CAP_NET_ADMIN ne riparas aparatan nodon, kiun via serva uzanto ne povas legi, kaj ripari la nodon ne donas al vi itinera aŭtoritaton. Kontrolu ambaŭ antaŭ ol ŝanĝi iun ajn el ili.
Kerna WireGuard kaj tunelaj programoj en uzula spaco ankaŭ ne havas identajn postulojn. La kerna modula vojo agordas ekzistantan interfacon per netlink, dum efektivigo en uzula spaco povas ankaŭ bezoni la aparaton kaj, por kelkaj transportoj, krudajn ingojn.
Legu la kuntekston: servo, ujo aŭ ŝelo
Kapablo en la reta nomspaco de la gastiganto povas efiki multe pli ol la sama operacio en intence izolita stako. Uja rulmedio kutime startas kun malgrandigita limiga aro; aldoni NET_ADMIN al ujo, kiu kunhavas la reton de la gastiganto, estas multe pli granda donaĵo ol aldoni ĝin al ujo kun propra reta nomspaco kaj sen gastigantaj surmetoj.
Por systemd-unuoj legu, kio efektive aplikiĝas, ne kion la unua dosiero ŝajne diras: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities raportas la efektivajn valorojn, kiujn povas esti agorditaj de drop-in, kiun vi forgesis. Petu la efektivan valoron, neniam la celitan. Ambient-kapabloj gravas, ĉar servo sen root perdas kapablojn trans exec sen ili.
Uzu la subtenatan agordon de la pakaĵo aŭ bildo kiel bazlinio. Ne aldonu permesojn por krudaj ingoj aŭ privilegian reĝimon ĉar alia lernilo listigis ilin por alia ilo; tiu rezonado transdonas nenion kaj kostas al vi la izoladon, kiun vi pagis. Se vi dubas, donu nenion kaj legu la notojn de la efektivigo por la preciza operacio, kiun vi bezonas.
Rigardu, kio okazas post kiam privilegioj falas
Multaj demonoj startas privilegie, agordas la interfacon, poste transiras al neprivilegia uzanto kaj konservas la tunelon. De tiu punkto la procezo jam ne povas aldoni itinero, reskribi fajroŝirma regulon aŭ malfermi novan privilegian aparaton, kio estas en ordo ĝis rekonekto bezonas ĝuste tion. Postaj dosierlegadoj kaj hokekzekutoj povas malsukcesi pro la sama kaŭzo.
Testu la tutan vivciklon anstataŭ la unuan sekundon: starto, renovigo aŭ rekonekto, kaj purigado ĉe halto. Unua sukcesa interfaca kreado ne pruvas, ke ĉiu posta privilegia operacio ankoraŭ funkcios, kaj la malsukceso kutime aperas horojn poste en produktado.
Efektivigoj, kiuj tenas la tunelon malfermita trans uzanta ŝanĝo, kutime parigas tion kun opcioj konservi la tunelon kaj la ŝlosilojn. Ĉe la systemd-flanko la ekvivalenta demando estas, ĉu la kapablaro de la unuo postvivas la uzantan ŝanĝon, kiun vi agordis.
Notu la donaĵon kaj ĝian kialon
Notu la precizan donaĵon, la operacion, kiun ĝi ebligas, kaj la eraron, kiun ĝi riparis. Unu linio en la enkondukaj notoj — «CAP_NET_ADMIN en la reta nomspaco de la unuo, necesa por itineraj ŝanĝoj post rekonekto» — sufiĉas por malhelpi la sekvan personon denove larĝigi la donaĵon.
Poste relegu la efektivan aron post ĉiu ĝisdatigo. Vendistoj aldonas funkciojn, bildoj ŝanĝas defaŭltojn, kaj kapablo, kiu estis nenecesa pasintjare, povas fariĝi portanta sen ke iu rimarku.