Kontener LXD nie otwiera /dev/net/tun? Sprawdź wpis unix-char

LXD udostępnia urządzenie znakowe hosta kontenerowi przez dodanie węzła urządzenia, a nie przez uczenie gościa tworzenia go. Jeśli kontener nie ma /dev/net/tun, host może mieć urządzenie, a gość nadal nie może go otworzyć. Wpis unix-char to połowa tej drogi po stronie menedżera i jest celowo węższy niż uprzywilejowany kontener. Dlatego węzeł hosta i węzeł kontenera zasługują na osobne kontrole.

Mechanizm jest dość krótki, by go obserwować: LXD rozwiązuje ścieżkę hosta, tworzy pasujący węzeł wewnątrz instancji i dodaje urządzenie do cgroup urządzeń kontenera. Potem proces gościa potrzebuje własnego uprawnienia i zdolności, by użyć węzła do czegokolwiek.

Co naprawdę zmienia wpis unix-char

Urządzenie unix-char każe LXD udostępnić jedno urządzenie znakowe hosta pod wybraną ścieżką wewnątrz kontenera. Wpis ma trzy istotne części: etykietę urządzenia używaną przez menedżera, ścieżkę source na hoście i path, który widzi gość. Tylko dwie ostatnie opisują samo urządzenie. Literówka w którejkolwiek z nich tworzy węzeł w miejscu, którego klient nigdy nie otwiera.

Na hoście urządzenie to zwykle /dev/net/tun. W kontenerze możesz zachować tę samą ścieżkę albo wybrać inną, ale ścieżka musi odpowiadać temu, czego oczekuje klient VPN. Zachowanie /dev/net/tun pozwala uniknąć drugiego problemu z konfiguracją, bo większość klientów otwiera tę ścieżkę bez pytania.

Menedżer stosuje wpis przy starcie instancji lub przy podłączeniu urządzenia na gorąco. Nie kopiuje sterownika do gościa i nie tworzy interfejsu tunelu. Udostępnia węzeł i zezwala na dostęp przez grupę kontrolną urządzeń kontenera.

Deklaruj urządzenie w instancji, nie w gościu

Dodaj wpis z kontekstu administracji LXD, podając instancję i etykietę, którą później rozpoznasz. Dla kontenera o nazwie vpnbox polecenie wygląda tak:

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

Etykieta tun jest lokalna dla konfiguracji instancji. Nie jest nazwą interfejsu i nie musi pasować do niczego w gościu. Jeśli profil już zapewnia to samo urządzenie, dodanie drugiego wpisu tworzy konflikt, a nie nadmiarowość, więc najpierw sprawdź efektywną konfigurację.

Edytowanie plików w kontenerze to zła warstwa. mknod w skrypcie startowym może sprawiać wrażenie, że działa w uprzywilejowanym kontenerze, a potem zniknąć przy odtworzeniu lub zawieść w mniej uprzywilejowanym. Zestaw urządzeń instancji należy do menedżera; pozwól mu też władać węzłem.

Dopasuj własność i tryb do procesu gościa

Wpis unix-char może ustawić uid, gid i mode dla węzła w kontenerze. Użyj ich, by pasowały do konta uruchamiającego klienta VPN, zamiast otwierać urządzenie wszystkim użytkownikom albo przełączać kontener w tryb uprzywilejowany.

Widoczność to nie to samo co uprawnienie. Węzeł należący do roota z trybem 600 jest widoczny dla usługi działającej jako nieuprzywilejowany użytkownik i nadal nie da się przez nią otworzyć. Sprawdź najpierw konto gościa, potem ustaw własność na to konto i trzymaj tryb nie szerszy, niż potrzebuje klient.

Proces potrzebuje też zdolności konfigurowania interfejsu tunelu, zwykle CAP_NET_ADMIN w przestrzeni nazw sieci kontenera. Przekazanie urządzenia nie daje tej zdolności, a przyznanie zdolności nie dostarcza urządzenia; to niezależne wymagania.

Wiedz, czego wpis nie daje

Widoczny węzeł to nie działający VPN. Pakiet klienta nadal trzeba zainstalować, profil nadal musi być ważny, a usługa nadal musi wystartować. Uwierzytelnianie, trasy i DNS pozostają zadaniem klienta, a błąd tam nie jest dowodem, że wpis urządzenia jest nieprawidłowy.

systemd może dodać kolejne ograniczenie. Jednostka z DeviceAllow lub zaostrzoną polityką urządzeń może odmówić dostępu do węzła dostarczonego przez menedżera kontenerów. Sprawdź politykę urządzeń jednostki, gdy węzeł istnieje, ale usługa zgłasza błąd uprawnień, i zmień tę politykę zamiast rozszerzać kontener.

Podłączanie na gorąco jest opcjonalne i jawne. Wpis z required=false wymaga ścieżki źródłowej i może pojawiać się lub znikać wraz ze zmianami urządzenia hosta. Taki cykl życia pasuje do sprzętu, który pojawia się i znika; dla urządzenia TUN potrzebnego VPN przy starcie opcjonalny wpis może sprawić, że usługa wystartuje, zanim warunek będzie istniał.

Sprawdź widoczność, otwieranie i interfejs w tej kolejności

Najpierw potwierdź węzeł w zamierzonym kontenerze. Ścieżka, numer główny i poboczny oraz własność powinny odpowiadać urządzeniu hosta i dodanemu wpisowi. Brak węzła oznacza, że menedżer nie zastosował wpisu albo zastosował go w innej instancji.

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

Następnie potwierdź, że konto usługi może go otworzyć. Krótki test jako to konto oddziela problem własności od problemu usługi. Na koniec uruchom klienta i potwierdź, że pojawia się interfejs tunelu; tylko ten trzeci krok dowodzi całej drogi, bo pierwsze dwa mogą przejść, gdy profil lub zdolność klienta są wciąż błędne.

Zapisz instancję, etykietę urządzenia, źródło na hoście, ścieżkę w gościu i konto właściciela, gdy zmiana zostanie zatwierdzona. Te pięć wartości musi zachować późniejsze odtworzenie, migracja lub zmiana profilu, a porównanie ich jest znacznie łatwiejsze niż błędu uprawnień bez kontekstu.