Watter Linux-vermoëns het jou VPN-proses nodig?
Koppelvlakopstelling, roetes, toesteltoegang en gewone sokkels is afsonderlike voorregte. Noem die bewerking wat misluk het voordat jy CAP_NET_ADMIN toeken.
’n VPN-daemon het bevoorregte netwerkbewerkings nodig, selfs al open gewone programme uitgaande sokkels heeltemal sonder voorregte. Daardie gaping is waar die meeste vermoëfoute begin: iemand sien ’n toestemmingsfout, ken die hele stel toe, en die diens werk om redes wat niemand later kan verduidelik nie. Die deurloop hieronder begin by die bewerking wat misluk het, karteer dit na een bevoegdheid, en kyk dan na die konteks waarin die proses werklik loop. Om as onbeperkte root te loop is vir sommige ontplooiings ’n geldige antwoord, maar dit behoort ’n besluit te wees eerder as ’n verstekwaarde.
Begin by die bewerking wat misluk het
Lees die fout voordat jy ’n handleiding lees. “Operation not permitted” op ’n koppelvlakverandering, ’n weiering om ’n toestelknooppunt oop te maak, en ’n bindfout op ’n lae poort is drie verskillende probleme met drie verskillende toekennings. As die proses begin en eers by die eerste roeteverandering misluk, sê dit ook dat die koppelvlak al geskep is, wat die antwoord aansienlik vernou.
Reproduseer die fout terwyl die diens gestop is, en begin dit dan in die voorgrond onder dieselfde gebruiker as die implementering dit toelaat. ’n Fout wat jy kan sien, is beter as ’n logreël waaroor jy moet raai, en dit maak die verskil tussen ’n vermoëprobleem en ’n SELinux- of AppArmor-weiering duidelik.
Karteer elke bewerking na een bevoegdheid
Die tabel is ’n vertrekpunt, nie ’n plaasvervanger vir die implementering se dokumentasie nie:
| 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 |
Twee rye in daardie tabel is dié wat mense verwar. Om /dev/net/tun oop te maak is ’n vraag oor lêertoestemmings; om die kernel te vra om te konfigureer wat jy oopgemaak het, is ’n vraag oor vermoëns. Om CAP_NET_ADMIN toe te ken maak nie ’n toestelknooppunt reg wat jou diensgebruiker nie kan lees nie, en om die knooppunt reg te maak gee jou nie roetebevoegdheid nie. Kontroleer albei voordat jy enigeen verander.
Kernel-WireGuard en gebruikerspasie-tunnelprogramme het ook nie identiese vereistes nie. Die kernelmodule-pad konfigureer ’n bestaande koppelvlak deur netlink, terwyl ’n gebruikerspasie-implementering ook die toestel nodig kan hê en, vir sommige vervoerders, rou sokkels.
Lees die konteks: diens, houer of dop
’n Vermoë in die gasheer se netwerknaamruimte kan baie meer raak as dieselfde bewerking binne ’n doelbewus geïsoleerde stapel. ’n Houerlooptyd begin gewoonlik met ’n verkleinde begrensingstel; om NET_ADMIN by ’n houer te voeg wat die gasheernetwerk deel, is ’n veel groter toekenning as om dit by een met sy eie netwerknaamruimte en geen gasheermonterings te voeg.
Lees vir systemd-eenhede wat werklik toegepas word eerder as wat die eenheidslêer skynbaar sê: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities rapporteer die effektiewe waardes, wat deur ’n drop-in gestel kan word wat jy vergeet het. Vra vir die effektiewe waarde, nooit die bedoelde een nie. Ambient-vermoëns maak saak omdat ’n nie-root-diens vermoëns oor exec verloor sonder hulle.
Gebruik die pakket of beeld se ondersteunde opstelling as die basislyn. Moenie rou-soketregte of bevoorregte modus byvoeg omdat ’n ander handleiding dit vir ’n ander hulpmiddel gelys het nie; daardie redenasie dra niks oor nie en kos jou die isolasie waarvoor jy betaal het. Wanneer jy twyfel, ken niks toe nie en lees die implementeringsnotas vir die presiese bewerking wat jy nodig het.
Kyk wat gebeur nadat voorregte daal
Baie daemons begin bevoorreg, konfigureer die koppelvlak, en sak dan na ’n onbevoorregte gebruiker en hou die tonnel. Van daardie punt af kan die proses nie meer ’n roete byvoeg, ’n firewallreël herskryf of ’n nuwe bevoorregte toestel oopmaak nie, wat goed is totdat ’n herverbinding presies dit nodig het. Later lêerlees en hook-uitvoering kan om dieselfde rede misluk.
Toets die hele lewensiklus eerder as die eerste sekonde: opstart, ’n hernuwing of herverbinding, en opruiming by stop. ’n Eerste suksesvolle koppelvlakskepping bewys nie dat elke latere bevoorregte bewerking nog sal werk nie, en die fout verskyn gewoonlik ure later in produksie.
Implementerings wat die tonnel oop hou oor ’n gebruikerwisseling, paar dit gewoonlik met opsies om die tonnel en sleutels te bewaar. Aan die systemd-kant is die ekwivalente vraag of die eenheid se vermoënstel die gebruikerwisseling oorleef wat jy gekonfigureer het.
Teken die toekenning en die rede daarvan aan
Skryf die presiese toekenning neer, die bewerking wat dit moontlik maak en die fout wat dit reggemaak het. Een reël in die ontplooiingsnotas — “CAP_NET_ADMIN in die eenheid se netwerknaamruimte, nodig vir roeteveranderinge ná herverbinding” — is genoeg om die volgende persoon te keer om die toekenning weer te verbreed.
Lees dan die effektiewe stel weer ná elke opgradering. Vervaardigers voeg funksies by, beelde verander verstekwaardes, en ’n vermoë wat verlede jaar onnodig was, kan dragend word sonder dat iemand dit agterkom.