Kontena ya LXD haiwezi kufungua /dev/net/tun? Angalia ingizo la unix-char
LXD lazima ipitishe kifaa cha TUN cha mwenyeji kwenye kontena kabla mteja wa VPN hajaweza kukitumia. Tazama unix-char inaongeza nini, nini haiongezi, na jinsi ya kuthibitisha.
LXD huonyesha kifaa cha herufi cha mwenyeji kwa kontena kwa kuongeza nodi ya kifaa, si kwa kumfundisha mgeni kuunda kimoja. Ikiwa kontena haina /dev/net/tun, kifaa kinaweza kuwa kwenye mwenyeji na mgeni bado ashindwe kukifungua. Ingizo la unix-char ni nusu ya njia hiyo kwa upande wa msimamizi, na kwa makusudi ni nyembamba kuliko kontena yenye fursa. Ndiyo sababu nodi ya mwenyeji na nodi ya kontena zinastahili ukaguzi tofauti.
Utaratibu ni mfupi vya kutosha kuubakiza machoni: LXD hutatua njia ya mwenyeji, huunda nodi inayolingana ndani ya mfano na huongeza kifaa kwenye cgroup ya vifaa vya kontena. Kisha mchakato wa mgeni unahitaji ruhusa na uwezo wake mwenyewe ili kutumia nodi kwa kitu chochote.
Ingizo la unix-char hubadilisha nini kwa hakika
Kifaa cha unix-char humwambia LXD kuonyesha kifaa kimoja cha herufi cha mwenyeji kwenye njia iliyochaguliwa ndani ya kontena. Ingizo lina sehemu tatu muhimu: lebo ya kifaa anayotumia msimamizi, njia source kwenye mwenyeji na path ambayo mgeni huiona. Mbili za mwisho pekee ndizo zinazoelezea kifaa chenyewe. Hitilafu ya uandishi katika mojawapo huunda nodi mahali ambapo mteja hufungua kamwe.
Kwenye mwenyeji kifaa kwa kawaida ni /dev/net/tun. Ndani ya kontena unaweza kubakiza njia hiyo hiyo au kuchagua nyingine, lakini njia lazima ilingane na kile mteja wa VPN anatarajia. Kubakiza /dev/net/tun huepusha tatizo la pili la usanidi, kwa sababu wateja wengi hufungua njia hiyo bila kuuliza.
Msimamizi hutumia ingizo wakati mfano unaanza au kifaa kinapounganishwa kwa moto. Hainakili kiendeshi ndani ya mgeni na haiundi kiolesura cha handaki. Huifanya nodi ionekane na huruhusu ufikiaji kupitia kikundi cha udhibiti cha vifaa vya kontena.
Tangaza kifaa kwenye mfano, si ndani ya mgeni
Ongeza ingizo kutoka muktadha wa utawala wa LXD, ukitaja mfano na lebo utakayoijua baadaye. Kwa kontena iitwayo vpnbox amri ni hii:
lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox
Lebo tun ni ya ndani kwa usanidi wa mfano. Si jina la kiolesura na haihitaji kulingana na kitu chochote ndani ya mgeni. Ikiwa profaili tayari hutoa kifaa hicho hicho, kuongeza ingizo la pili huunda mgongano badala ya ziada, kwa hiyo kagua usanidi unaofanya kazi kwanza.
Kuhariri faili ndani ya kontena ni tabaka isiyo sahihi. mknod katika hati ya kuanza inaweza kuonekana inafanya kazi kwenye kontena yenye fursa, kisha kutoweka wakati wa kuunda upya au kushindwa kwenye moja yenye fursa ndogo. Msimamizi anamiliki seti ya vifaa vya mfano; acha pia amiliki nodi.
Linganisha umiliki na modi na mchakato wa mgeni
Ingizo la unix-char linaweza kuweka uid, gid na mode kwa nodi ndani ya kontena. Zitumie kulingana na akaunti inayoendesha mteja wa VPN, badala ya kufungua kifaa kwa kila mtumiaji au kubadilisha kontena kwenda modi yenye fursa.
Kuonekana si sawa na ruhusa. Nodi inayomilikiwa na root yenye modi 600 inaonekana kwa huduma inayoendesha kama mtumiaji asiye na fursa na bado haiwezi kuifungua. Kagua akaunti ya mgeni kwanza, kisha weka umiliki kwa akaunti hiyo, na usiweke modi pana kuliko mteja anahitaji.
Mchakato pia unahitaji uwezo wa kusanidi kiolesura cha handaki, kwa kawaida CAP_NET_ADMIN katika nafasi ya majina ya mtandao ya kontena. Kupitisha kifaa hakupi uwezo huo, na kutoa uwezo hakutoi kifaa; ni mahitaji huru.
Jua ingizo halipe na nini
Nodi inayoonekana si VPN inayofanya kazi. Kifurushi cha mteja bado kinahitaji kusakinishwa, profaili bado inapaswa kuwa halali, na huduma bado inapaswa kuanza. Uthibitishaji, njia na DNS zinabaki kazi ya mteja, na kushindwa hapo si uthibitisho kwamba ingizo la kifaa si sahihi.
systemd inaweza kuongeza kizuizi kingine. Kitengo kilicho na DeviceAllow au sera ya vifaa iliyoimarishwa kinaweza kukataa ufikiaji wa nodi ambayo msimamizi wa kontena ameitoa. Kagua sera ya vifaa ya kitengo wakati nodi ipo lakini huduma inaripoti hitilafu ya ruhusa, na ubadilishe sera hiyo badala ya kupanua kontena.
Uunganishaji wa moto ni wa hiari na wazi. Ingizo lenye required=false linahitaji njia ya chanzo na linaweza kuonekana au kutoweka kifaa cha mwenyeji kinapobadilika. Mzunguko huo wa maisha unafaa vifaa vinavyokuja na kwenda; kwa kifaa cha TUN ambacho VPN inahitaji wakati wa kuwasha, ingizo la hiari linaweza kuacha huduma ianze kabla sharti lake halipo.
Thibitisha kuonekana, ufunguzi na kiolesura kwa mpangilio huo
Kwanza thibitisha nodi ndani ya kontena iliyokusudiwa. Njia, namba kuu na ndogo na umiliki vinapaswa kulingana na kifaa cha mwenyeji na ingizo uliloongeza. Nodi inayokosekana ina maana msimamizi hakutumia ingizo, au alilitumia kwenye mfano mwingine.
lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'
Kisha thibitisha kwamba akaunti ya huduma inaweza kuifungua. Jaribio fupi kama akaunti hiyo hutenganisha tatizo la umiliki na tatizo la huduma. Mwisho, anza mteja na uthibitishe kwamba kiolesura cha handaki kinaonekana; hatua hiyo ya tatu pekee ndiyo inayothibitisha njia yote, kwa sababu mbili za kwanza zinaweza kupita wakati profaili au uwezo wa mteja bado si sahihi.
Rekodi mfano, lebo ya kifaa, chanzo cha mwenyeji, njia ya mgeni na akaunti inayomiliki wakati mabadiliko yanapoidhinishwa. Thamani hizo tano ndizo ambazo uundaji upya, uhamishaji au mabadiliko ya profaili baadaye lazima uzihifadhi, na ni rahisi zaidi kuzilinganisha kuliko hitilafu ya ruhusa isiyo na muktadha.