Zein Linux gaitasun behar ditu zure VPN prozesuak?
Interfazearen konfigurazioa, ibilbideak, gailuetarako sarbidea eta socket arruntak pribilegio bereiziak dira. Prozesuan huts egin duen eragiketa izendatu CAP_NET_ADMIN eman aurretik.
VPN daemon batek sare-eragiketa pribilegiatuak behar ditu, aplikazio arruntek irteerako socketak inolako pribilegiorik gabe irekitzen badituzte ere. Hutsune horretan hasten dira gaitasun-errore gehienak: norbaitek baimen-errore bat ikusten du, multzo osoa ematen du, eta zerbitzuak gero inork azaldu ezin dituen arrazoiengatik egiten du lan. Beheko ibilbidea huts egin duen eragiketatik abiatzen da, aginte bakar batekin lotzen du eta, ondoren, prozesua benetan exekutatzen den testuingurua egiaztatzen du. Root mugagabe gisa exekutatzea erantzun baliozkoa da zabalpen batzuetarako, baina erabakia izan beharko luke, ez lehenetsitako balioa.
Hasi huts egin duen eragiketatik
Irakurri errorea tutoriala irakurri aurretik. Interfaze-aldaketa batean «eragiketa ez da onartzen», gailu-nodo bat irekitzeari uko egitea eta portu baxu batean bind huts egitea hiru arazo desberdin dira, hiru baimen desberdinekin. Prozesuak abiarazten bada eta lehen ibilbide-aldaketan soilik huts egiten badu, horrek ere esaten du interfazearen sorrera dagoeneko lortu dela, eta horrek erantzuna nabarmen murrizten du.
Erreproduzitu hutsegitea zerbitzua geldituta dagoela eta, ondoren, abiarazi lehen planoan erabiltzaile berarekin, inplementazioak horretarako baimena ematen badu. Ikus dezakezun errore bat asmatu behar duzun log-lerro bat baino hobea da, eta gaitasun-arazo baten eta SELinux edo AppArmor ukapen baten arteko aldea argi uzten du.
Lotu eragiketa bakoitza aginte bakar batekin
Taula abiapuntuko mapa bat da, ez inplementazioaren dokumentazioaren ordezko:
| 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 |
Taula horretako bi errenkadak dira jendeak nahasten dituenak. /dev/net/tun irekitzea fitxategi-baimenen kontua da; ireki duzuna konfigura dezan nukleoari eskatzea gaitasunen kontua da. CAP_NET_ADMIN emateak ez du konpontzen zure zerbitzu-erabiltzaileak irakurri ezin duen gailu-nodo bat, eta nodoa konpontzeak ez dizu ibilbide-aginterik ematen. Egiaztatu biak, edozein aldatu aurretik.
Nukleoko WireGuardek eta erabiltzaile-espazioko tunel-programek ere ez dituzte baldintza berak. Nukleo-moduluaren bideak lehendik dagoen interfaze bat konfiguratzen du netlink bidez, erabiltzaile-espazioko inplementazio batek gailua eta, zenbait garraiobiderentzat, socket gordinak ere behar izan ditzakeen bitartean.
Irakurri testuingurua: zerbitzua, edukiontzia edo shell-a
Ostalariaren sare-izen-espazioko gaitasun batek eragin askoz handiagoa izan dezake nahita isolatutako pila baten barruko eragiketa berak baino. Edukiontzien exekuzio-ingurunea muga-multzo murriztu batekin hasten da normalean; ostalariaren sarea partekatzen duen edukiontzi bati NET_ADMIN gehitzea askoz baimen handiagoa da bere sare-izen-espazio propioa duen eta ostalariaren muntaketarik ez duen bati gehitzea baino.
systemd unitateetan, irakurri benetan aplikatzen dena eta ez unitate-fitxategiak esaten duela dirudiena: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities balio eraginkorrak jakinarazten ditu, ahaztu duzun drop-in batek ezarri ditzakeenak. Eskatu balio eraginkorra, inoiz ez aurreikusitakoa. Ambient gaitasunek garrantzia dute, root ez den zerbitzu batek gaitasunak galtzen baititu exec zehar horiek gabe.
Hartu paketearen edo irudiaren konfigurazio onartua oinarritzat. Ez gehitu socket gordinen baimenik ezta modu pribilegiatua ere beste tutorial batek beste tresna baterako zerrendatu dituelako; arrazoibide horrek ez du ezer eramaten eta ordaindu zenuen isolamendua galtzen duzu. Zalantzarik baduzu, ez eman ezer eta irakurri inplementazioaren oharrak behar duzun eragiketa zehatzerako.
Behatu zer gertatzen den pribilegioak erori ondoren
Daemon asko pribilegioekin hasten dira, interfazea konfiguratzen dute, gero erabiltzaile ez-pribilegiatu batera jaisten dira eta tunela mantentzen dute. Puntu horretatik aurrera prozesuak ezin du ibilbiderik gehitu, firewall araurik berridatzi edo gailu pribilegio berririk ireki, eta hori ondo dago berriz konektatzeak hain zuzen hori behar duen arte. Geroagoko fitxategi-irakurketek eta hook exekuzioek arrazoi beragatik huts egin dezakete.
Probatu bizi-ziklo osoa eta ez lehen segundoa: abiaraztea, berritzea edo berriz konektatzea eta gelditzean garbitzea. Interfazea lehen aldiz ongi sortzeak ez du frogatzen geroagoko eragiketa pribilegiatu guztiek funtzionatzen jarraituko dutenik, eta hutsegitea ordu batzuk geroago agertu ohi da produkzioan.
Erabiltzaile-aldaketa zehar tunela irekita mantentzen duten inplementazioek tunela eta gakoak gordetzeko aukerekin uztartzen dute hori. systemd aldean, baliokidea den galdera da unitatearen gaitasun-multzoak konfiguratu duzun erabiltzaile-aldaketa gainditzen duen.
Erregistratu emaniko baimena eta haren arrazoia
Idatzi baimen zehatza, ahalbidetzen duen eragiketa eta konpondu zuen errorea. Hedapen-oharretan lerro bat — «CAP_NET_ADMIN unitatearen sare-izen-espazioan, berriz konektatu ondorengo ibilbide-aldaketetarako beharrezkoa» — nahikoa da hurrengo pertsonak baimena berriro zabal ez dezan.
Ondoren, irakurri berriro multzo eraginkorra bertsio-berritze bakoitzaren ondoren. Hornitzaileek funtzioak gehitzen dituzte, irudiek lehenetsitako balioak aldatzen dituzte, eta iaz beharrezkoa ez zen gaitasun bat euskarri bihur daiteke inork nabaritu gabe.