Kontejner LXD nemůže otevřít /dev/net/tun? Zkontrolujte záznam unix-char

LXD zpřístupňuje znakové zařízení hostitele kontejneru přidáním uzlu zařízení, ne tak, že by hosta učil ho vytvářet. Pokud kontejner nemá /dev/net/tun, zařízení může být na hostiteli a host ho přesto nemusí otevřít. Záznam unix-char je polovina této cesty na straně správce a je záměrně užší než privilegovaný kontejner. Proto si uzel hostitele a uzel kontejneru zaslouží samostatné kontroly.

Mechanismus je dost krátký na to, aby zůstal na dohled: LXD vyhodnotí cestu na hostiteli, vytvoří odpovídající uzel uvnitř instance a přidá zařízení do cgroup zařízení kontejneru. Proces hosta pak potřebuje vlastní oprávnění a schopnost, aby uzel k něčemu použil.

Co záznam unix-char skutečně mění

Zařízení unix-char říká LXD, aby zpřístupnilo jedno znakové zařízení hostitele na zvolené cestě uvnitř kontejneru. Záznam má tři důležité části: popisek zařízení, který používá správce, cestu source na hostiteli a path, kterou vidí host. Jen poslední dvě popisují zařízení samotné. Překlep v kterékoli z nich vytvoří uzel na místě, které klient nikdy neotevře.

Na hostiteli je zařízení obvykle /dev/net/tun. Uvnitř kontejneru můžete ponechat stejnou cestu nebo zvolit jinou, ale cesta se musí shodovat s tím, co klient VPN očekává. Ponechání /dev/net/tun se vyhne druhému problému s konfigurací, protože většina klientů tuto cestu otevírá bez ptaní.

Správce záznam použije při startu instance nebo při horkém připojení zařízení. Nezkopíruje ovladač do hosta a nevytvoří tunelové rozhraní. Zpřístupní uzel a povolí přístup přes skupinu ovládání zařízení kontejneru.

Deklarujte zařízení na instanci, ne uvnitř hosta

Přidejte záznam z administrativního kontextu LXD, s názvem instance a popiskem, který později poznáte. Pro kontejner s názvem vpnbox je příkaz:

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

Popisek tun je místní pro konfiguraci instance. Není to název rozhraní a nemusí se shodovat s ničím v hostovi. Pokud profil už stejné zařízení poskytuje, přidání druhého záznamu vytvoří konflikt, ne redundanci, takže nejdřív prohlédněte efektivní konfiguraci.

Upravovat soubory uvnitř kontejneru je špatná vrstva. mknod ve startovacím skriptu může vypadat, že v privilegovaném kontejneru funguje, a pak při opětovném vytvoření zmizí nebo v méně privilegovaném selže. Množinu zařízení instance vlastní správce; nechte ho vlastnit i uzel.

Sladěte vlastnictví a režim s procesem hosta

Záznam unix-char umí nastavit uid, gid a mode pro uzel uvnitř kontejneru. Použijte je ke sladění s účtem, který spouští klienta VPN, místo otevírání zařízení všem uživatelům nebo přepnutí kontejneru do privilegovaného režimu.

Viditelnost není totéž co oprávnění. Uzel vlastněný rootem s režimem 600 je viditelný pro službu běžící jako neprivilegovaný uživatel a přesto ji nelze otevřít. Zkontrolujte nejdřív účet hosta, poté nastavte vlastnictví na tento účet a držte režim ne širší, než klient potřebuje.

Proces také potřebuje schopnost konfigurovat tunelové rozhraní, obvykle CAP_NET_ADMIN v síťovém jmenném prostoru kontejneru. Předání zařízení tuto schopnost nedává a udělení schopnosti neposkytuje zařízení; jsou to nezávislé požadavky.

Vězte, co záznam nedává

Viditelný uzel není fungující VPN. Balíček klienta se stále musí nainstalovat, profil stále musí být platný a služba stále musí nastartovat. Ověřování, trasy a DNS zůstávají prací klienta a selhání tam není důkazem, že záznam zařízení je špatný.

systemd může přidat další omezení. Unit s DeviceAllow nebo zpevněnou politikou zařízení může odepřít přístup k uzlu, který dodal správce kontejnerů. Zkontrolujte politiku zařízení unitu, když uzel existuje, ale služba hlásí chybu oprávnění, a změňte tuto politiku, místo abyste kontejner rozšiřovali.

Horké připojení je volitelné a explicitní. Záznam s required=false potřebuje zdrojovou cestu a může se objevit nebo zmizet podle toho, jak se zařízení hostitele mění. Takový životní cyklus sedí hardwaru, který přichází a odchází; pro zařízení TUN, které VPN potřebuje při bootu, může volitelný záznam nechat službu startovat dřív, než existuje její předpoklad.

Ověřte viditelnost, otevření a rozhraní v tomto pořadí

Nejdřív potvrďte uzel uvnitř zamýšleného kontejneru. Cesta, hlavní a vedlejší číslo a vlastnictví se musí shodovat se zařízením hostitele a se záznamem, který jste přidali. Chybějící uzel znamená, že správce záznam nepoužil, nebo ho použil na jinou instanci.

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

Poté potvrďte, že ho účet služby umí otevřít. Krátký test pod tímto účtem oddělí problém vlastnictví od problému služby. Nakonec spusťte klienta a potvrďte, že se objeví tunelové rozhraní; jen tento třetí krok dokazuje celou cestu, protože první dva mohou projít, zatímco profil nebo schopnost klienta jsou stále špatné.

Zapište instanci, popisek zařízení, zdroj na hostiteli, cestu v hostovi a vlastnící účet, když je změna schválena. Těchto pět hodnot musí pozdější opětovné vytvoření, migrace nebo změna profilu zachovat, a je mnohem snazší je porovnat než chybu oprávnění bez kontextu.