Kontajner LXD nevie otvoriť /dev/net/tun? Skontrolujte záznam unix-char

LXD sprístupňuje znakové zariadenie hostiteľa kontajneru pridaním uzla zariadenia, nie tým, že by hosťa učil ho vytvárať. Ak kontajner nemá /dev/net/tun, zariadenie môže byť na hostiteľovi a hosť ho napriek tomu nemusí otvoriť. Záznam unix-char je polovica tejto cesty na strane správcu a je zámerne užší než privilegovaný kontajner. Preto si uzol hostiteľa a uzol kontajnera zaslúžia samostatné kontroly.

Mechanizmus je dosť krátky na to, aby zostal v dohľade: LXD vyhodnotí cestu na hostiteľovi, vytvorí zodpovedajúci uzol v inštancii a pridá zariadenie do cgroup zariadení kontajnera. Proces hosťa potom potrebuje vlastné oprávnenie a schopnosť, aby uzol na čokoľvek použil.

Čo záznam unix-char skutočne mení

Zariadenie unix-char hovorí LXD, aby sprístupnilo jedno znakové zariadenie hostiteľa na zvolenej ceste v kontajneri. Záznam má tri dôležité časti: označenie zariadenia, ktoré používa správca, cestu source na hostiteľovi a path, ktorú vidí hosť. Iba posledné dve opisujú samotné zariadenie. Preklep v ktorejkoľvek z nich vytvorí uzol na mieste, ktoré klient nikdy neotvorí.

Na hostiteľovi je zariadenie zvyčajne /dev/net/tun. V kontajneri môžete zachovať rovnakú cestu alebo zvoliť inú, ale cesta sa musí zhodovať s tým, čo klient VPN očakáva. Zachovanie /dev/net/tun sa vyhne druhému problému s konfiguráciou, pretože väčšina klientov túto cestu otvára bez pýtania.

Správca záznam použije pri štarte inštancie alebo pri horúcom pripojení zariadenia. Nekopíruje ovládač do hosťa a nevytvára tunelové rozhranie. Zviditeľní uzol a povolí prístup cez skupinu ovládania zariadení kontajnera.

Deklarujte zariadenie na inštancii, nie vnútri hosťa

Pridajte záznam z administratívneho kontextu LXD, s názvom inštancie a označením, ktoré neskôr spoznáte. Pre kontajner s názvom vpnbox je príkaz:

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

Označenie tun je lokálne pre konfiguráciu inštancie. Nie je názvom rozhrania a nemusí sa zhodovať s ničím v hosťovi. Ak profil už poskytuje to isté zariadenie, pridanie druhého záznamu vytvorí konflikt, nie redundanciu, takže najprv pozrite efektívnu konfiguráciu.

Upravovať súbory v kontajneri je nesprávna vrstva. mknod v štartovacom skripte môže vyzerať, že na privilegovanom kontajneri funguje, a potom pri opätovnom vytvorení zmizne alebo na menej privilegovanom zlyhá. Množinu zariadení inštancie vlastní správca; nechajte ho vlastniť aj uzol.

Zlaďte vlastníctvo a režim s procesom hosťa

Záznam unix-char môže nastaviť uid, gid a mode pre uzol v kontajneri. Použite ich na zladenie s účtom, ktorý spúšťa klienta VPN, namiesto otvárania zariadenia všetkým používateľom alebo prepnutia kontajnera do privilegovaného režimu.

Viditeľnosť nie je to isté ako oprávnenie. Uzol vo vlastníctve roota s režimom 600 je viditeľný pre službu bežiacu ako neprivilegovaný používateľ a napriek tomu ju nemožno otvoriť. Najprv skontrolujte účet hosťa, potom nastavte vlastníctvo na tento účet a držte režim nie širší, než klient potrebuje.

Proces tiež potrebuje schopnosť konfigurovať tunelové rozhranie, zvyčajne CAP_NET_ADMIN v sieťovom mennom priestore kontajnera. Odovzdanie zariadenia túto schopnosť nedáva a udelenie schopnosti neposkytuje zariadenie; sú to nezávislé požiadavky.

Vedzte, čo záznam nedáva

Viditeľný uzol nie je fungujúca VPN. Balík klienta sa stále musí nainštalovať, profil stále musí byť platný a služba stále musí naštartovať. Overovanie, trasy a DNS zostávajú prácou klienta a zlyhanie tam nie je dôkazom, že záznam zariadenia je nesprávny.

systemd môže pridať ďalšie obmedzenie. Unit s DeviceAllow alebo spevnenou politikou zariadení môže odmietnuť prístup k uzlu, ktorý dodal správca kontajnerov. Skontrolujte politiku zariadení unitu, keď uzol existuje, ale služba hlási chybu oprávnenia, a zmeňte tú politiku namiesto rozšírenia kontajnera.

Horúce pripojenie je voliteľné a explicitné. Záznam s required=false potrebuje zdrojovú cestu a môže sa objaviť alebo zmiznúť podľa toho, ako sa mení zariadenie hostiteľa. Taký životný cyklus sedí hardvéru, ktorý prichádza a odchádza; pre zariadenie TUN, ktoré VPN potrebuje pri bootovaní, môže voliteľný záznam nechať službu štartovať skôr, než existuje jej predpoklad.

Overte viditeľnosť, otvorenie a rozhranie v tomto poradí

Najprv potvrďte uzol v zamýšľanom kontajneri. Cesta, hlavné a vedľajšie číslo a vlastníctvo sa musia zhodovať so zariadením hostiteľa a so záznamom, ktorý ste pridali. Chýbajúci uzol znamená, že správca záznam nepoužil alebo ho použil na inú inštanciu.

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

Potom potvrďte, že účet služby ho vie otvoriť. Krátky test pod týmto účtom oddelí problém vlastníctva od problému služby. Nakoniec spustite klienta a potvrďte, že sa objaví tunelové rozhranie; iba tento tretí krok dokazuje celú cestu, pretože prvé dva môžu prejsť, kým profil alebo schopnosť klienta sú stále nesprávne.

Zapíšte inštanciu, označenie zariadenia, zdroj na hostiteľovi, cestu v hosťovi a vlastniaci účet, keď je zmena schválená. Týchto päť hodnôt musí neskoršie opätovné vytvorenie, migrácia alebo zmena profilu zachovať a je oveľa jednoduchšie ich porovnať než chybu oprávnenia bez kontextu.