OpenVPN katika Docker haiwezi kufungua /dev/net/tun: nini kinakosekana

Picha za kontena zinaweza kubeba kila OpenVPN binary na faili ya usanidi inayohitajika na bado kushindwa katika wito wa kwanza wa mtandao. Kosa linataja /dev/net/tun kwa sababu programu iliomba kernel interface ya TUN na kontena halikuwa na nodi ya kifaa au uwezo wa kuunda moja. Hizi ni ruhusa mbili tofauti, na kurekebisha moja kunaacha nyingine mahali ilipokuwa.

Kuzitenganisha kunahitaji amri moja kwa kila moja. Ujumbe wa kosa baada ya hapo unakuambia ulikuwa umesimama kwenye mpaka gani kwa kweli.

Nodi ya kifaa na uwezo ni milango miwili

Nodi ya kifaa ni kitu cha mfumo wa faili, kwa hiyo kontena linahitaji kuiona katika nafasi yake ya majina ya mount. Uwezo ni ruhusa, kwa hiyo mchakato unahitaji CAP_NET_ADMIN katika nafasi ya majina ambapo interface itaundwa. Kupitisha kifaa bila uwezo kunakupa nodi inayofunguka na ioctl inayoshindwa. Kutoa uwezo bila kifaa kunaacha programu isiweze kufungua chochote, ndiyo sababu zote mbili huonekana pamoja katika mifano.

Mpangilio wa devices wa Docker hupanga kifaa cha mwenyeji ndani ya kontena, wakati cap_add hurekebisha seti ya uwezo. Bind mount ya njia hiyo hiyo huweka faili kwenye mwonekano bila kutumia maana ya ufikiaji wa kifaa.

Izalisha tena nje ya faili ya Compose

Kabla ya kuhariri huduma, hakikisha mwenyeji ana kifaa na kwamba kontena tupu linaweza kuunda interface. Amri iliyo hapa chini ni ndogo kwa makusudi, na lengo lake pekee ni kutenganisha tatizo la mwenyeji na tatizo la compose. Ikishindwa, hakuna mabadiliko ya compose yatakayosaidia.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

Nodi inayokosekana kwenye mwenyeji inamaanisha moduli ya tun haipatikani, jambo ambalo ni marekebisho upande wa mwenyeji na si wa kontena. Nodi iliyopo lakini isiyoweza kufunguliwa ndani ya kontena inaonyesha ufikiaji wa kifaa, na ujumbe utasema permission denied badala ya no such file. Mpangilio wa kushindwa hivi viwili ndio uchunguzi wote. Andika ni kipi ulichokiona kabla ya kubadilisha bendera yoyote.

Makosa baada ya TUN ni matatizo tofauti

Mara interface inapotokea, kushindwa kunakofuata kuna mmiliki tofauti. Makosa ya uthibitishaji yanamaanisha tunnel ilifika kwa seva na vitambulisho vilikataliwa, kwa hiyo mabadiliko ya uwezo hayatasaidia. Tunnel inayojengwa wakati programu bado zinashindwa inaonyesha njia, upelekaji, utatuzi wa DNS ndani ya kontena au mpangilio wa mtandao wa kontena yenyewe. Kila moja ya haya ni swali la kawaida la mtandao ambalo ruhusa ya TUN haiwezi kujibu. Kurudia jaribio la awali baada ya kila mabadiliko huzuia kushindwa kuunganika kuwa hisia moja.

Kunakili kila mpangilio kutoka kwa mfano unaofanya kazi ndiyo njia ambayo marekebisho madogo huwa ufafanuzi wa huduma usioweza kusomwa. Leta tu yale ambayo usambazaji huu unahitaji na andika kwa nini kila moja liko hapo.

Thibitisha interface ndani ya kontena

Angalia interface na seti ya uwezo kutoka ndani ya kontena linaloendesha na si kutoka kwa mwenyeji. Amri zilizo hapa chini zinaonyesha nodi ya kifaa, orodha ya uwezo na kama interface inaweza kuundwa kabisa. Zifanye katika kontena lile lile linaloendesha mteja, na usakinishe zana ikiwa picha ni ndogo.

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

Uwezo uliopo katika bounding set lakini haupo katika effective set hujiendesha tofauti na ule ambao haujawahi kutolewa, na capsh inaonyesha zote mbili. Ikiwa nodi ipo na uwezo upo wakati uundaji bado unashindwa, mazingira ya utekelezaji yanalazimisha kitu kingine, kama wasifu wa seccomp au sera ya AppArmor inayozuia operesheni. Hiyo ni mpaka wa tatu, unaoandikwa na mazingira ya utekelezaji na si na programu.

Andika bendera za kontena, picha na kosa kamili kutoka kwa kila jaribio. Mtu anayefuata kusoma madokezo hayo ataweza kusema mlango gani ulikuwa umefungwa bila kurudia uchunguzi wote.