Waarom bevoorregte modus wyer is as wat ’n VPN nodig het

Die houer wou nie sy tonnel oopmaak nie, so die bevoorregte vlag is ingesit, en nou werk dit. Wat daardie reeks vasgestel het, is dat ten minste een toestemming ontbreek het, en dit sê niks oor watter een nie. Bevoorregte modus verleen ’n stel vermoëns en toesteltoegang wat veel wyer is as wat ’n tonnelkoppelvlak nodig het.

Wat die vlag werklik verander

’n Bevoorregte houer ontvang breë vermoëns en toegang tot gasheertoestelle, wat ’n veel groter toekenning is as wat die netwerkpad vereis. Die presiese stel word deur die runtime gedokumenteer eerder as deur oorlewering vasgestel, en die Docker dokumentasie vir houeruitvoering beskryf die beskikbare voorregopsies. Om dit een keer te lees, is genoeg om te sien dat tonneling ’n klein deel van die geheel is.

Twee smaller vereistes dek die meeste VPN-houers. Om ’n koppelvlak te konfigureer, vereis die netwerkadministrasievermoë, en om die tonneltoestel oop te maak, vereis toegang tot daardie spesifieke toestelknooppunt. Dit is afsonderlike toekennings, en om albei te verskaf is steeds smaller as die algemene opsie. Die res van die bevoorregte stel het niks met die tonnel te doen nie. Dit bestaan vir werkvragte wat werklik toegang op gasheervlak nodig het, en ’n VPN-houer is gewoonlik nie een daarvan nie.

Pas elke fout by een voorvereiste

Die foutboodskap sê vir jou watter voorvereiste ontbreek as jy dit lees voordat jy dit onderdruk. ’n Boodskap oor ’n toestelknooppunt noem die toestel, ’n boodskap oor ’n bewerking wat nie toegelaat word nie noem ’n vermoë, en ’n boodskap oor ’n module of ’n sysctl noem kerneondersteuning. Elkeen daarvan het ’n ander oplossing, en net een daarvan is ’n vermoë.

’n Ontbrekende konfigurasielêer bly ontbreek nadat elke vermoë toegestaan is, en daarom verander bevoorregte modus soms heeltemal niks nie. Die houer begin, die tonnel misluk steeds, en die werklike fout het nooit oor toestemmings gegaan nie. Kerneondersteuning is die derde geval en die maklikste om verkeerd te lees. ’n Module wat nie op die gasheer gelaai is nie, kan nie van binne ’n onbevoorregte houer gelaai word nie, en om meer vermoëns binne die houer toe te staan, verander nie die gasheer se toestand nie.

Kontroleer die vereiste, nie die simptoom nie

Begin by die minimale aanroep wat die beeld dokumenteer, voer dit uit en hou die presiese mislukkingsteks. Voeg dan een toekenning op ’n slag by en let op watter byvoeging die resultaat verander het.

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

’n Houer wat die toestel kan sien en die vermoë kan hou maar steeds misluk, sê vir jou die probleem is elders. Dit is ’n nuttige resultaat, en bevoorregte modus sou dit verberg het.

Kontroleer ook die toesteltoestemmings op die gasheer, want ’n korrek toegestane toestelknooppunt met die verkeerde groepbesit lewer dieselfde fout as ’n ontbrekende toekenning.

Teken die nouste toekenning aan wat werk

Skryf elke toestel en vermoë neer wat die ontplooiing nodig het, saam met die fout wat dit geregverdig het. Daardie rekord is wat die volgende persoon in staat stel om iets veilig te verwyder, en dit is wat ’n ouditeur sal vra wanneer ’n houer as bevoorreg gerapporteer word.

Hersien ook die omliggende konteks, want gasheernetwerking, gasheermonterings en runtime-opsies kan elkeen die impak van ’n toestemmingstoekenning verbreed. ’n Geïsoleerde laboratoriumaanroep wat almal kombineer, is nie ’n produksiekonfigurasie nie, hoe goed dit ook gewerk het. Toets die toepassing, sy DNS-gedrag en ’n tonnelfout voordat jy die ontplooiing as klaar beskou. Toestemming om ’n koppelvlak te skep, is nie ’n uitgangsbeleid nie, en ’n houer wat perfek kan tonnel, stuur steeds alles wat die toepassing stuur.