Containerul LXD nu poate deschide /dev/net/tun? Verificați intrarea unix-char

LXD expune un dispozitiv de caractere al gazdei unui container adăugând un nod de dispozitiv, nu învățând oaspetele să creeze unul. Dacă containerul nu are /dev/net/tun, gazda poate avea dispozitivul și oaspetele tot nu îl poate deschide. Intrarea unix-char este jumătatea dinspre administrator a acestei căi și este în mod deliberat mai îngustă decât un container privilegiat. De aceea nodul gazdei și nodul containerului merită verificări separate.

Mecanismul este suficient de scurt pentru a fi urmărit: LXD rezolvă o cale a gazdei, creează un nod corespunzător în instanță și adaugă dispozitivul în cgroup-ul de dispozitive al containerului. Apoi procesul oaspetelui are nevoie de permisiunea și de capacitatea proprie pentru a folosi nodul la orice.

Ce schimbă de fapt intrarea unix-char

Un dispozitiv unix-char îi spune lui LXD să expună un dispozitiv de caractere al gazdei pe o cale aleasă în container. Intrarea are trei părți importante: eticheta dispozitivului folosită de administrator, calea source pe gazdă și path pe care îl vede oaspetele. Doar ultimele două descriu dispozitivul în sine. O greșeală de tastare în oricare dintre ele produce un nod într-un loc pe care clientul nu îl deschide niciodată.

Pe gazdă, dispozitivul este de obicei /dev/net/tun. În container puteți păstra aceeași cale sau alege alta, dar calea trebuie să corespundă cu ceea ce așteaptă clientul VPN. Păstrarea /dev/net/tun evită o a doua problemă de configurare, pentru că majoritatea clienților deschid acea cale fără să întrebe.

Administratorul aplică intrarea la pornirea instanței sau la conectarea la cald a dispozitivului. Nu copiază un driver în oaspete și nu creează o interfață de tunel. Face nodul vizibil și permite accesul prin grupul de control al dispozitivelor al containerului.

Declarați dispozitivul pe instanță, nu în oaspete

Adăugați intrarea din contextul de administrare LXD, numind instanța și o etichetă pe care o veți recunoaște mai târziu. Pentru un container numit vpnbox, comanda este:

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

Eticheta tun este locală configurației instanței. Nu este un nume de interfață și nu trebuie să corespundă cu nimic din oaspete. Dacă un profil furnizează deja același dispozitiv, adăugarea unei a doua intrări creează un conflict, nu o redundanță, așa că examinați mai întâi configurația efectivă.

Editarea fișierelor în container este stratul greșit. Un mknod într-un script de pornire poate părea că funcționează pe un container privilegiat și apoi dispare la recreare sau eșuează pe unul mai puțin privilegiat. Administratorul deține setul de dispozitive al instanței; lăsați-l să dețină și nodul.

Aliniați proprietatea și modul la procesul oaspetelui

Intrarea unix-char poate seta uid, gid și mode pentru nodul din container. Folosiți-le pentru a corespunde contului care rulează clientul VPN, în loc să deschideți dispozitivul pentru toți utilizatorii sau să comutați containerul în mod privilegiat.

Vizibilitatea nu este același lucru cu permisiunea. Un nod deținut de root cu modul 600 este vizibil serviciului care rulează ca utilizator neprivilegiat și tot nu poate fi deschis de acesta. Verificați mai întâi contul oaspetelui, apoi setați proprietatea pe acel cont și păstrați modul nu mai larg decât are nevoie clientul.

Procesul are nevoie și de capacitatea de a configura o interfață de tunel, de obicei CAP_NET_ADMIN în spațiul de nume de rețea al containerului. Transmiterea dispozitivului nu acordă acea capacitate, iar acordarea capacității nu furnizează dispozitivul; sunt cerințe independente.

Aflați ce nu acordă intrarea

Un nod vizibil nu este o VPN funcțională. Pachetul clientului tot trebuie instalat, profilul tot trebuie să fie valid și serviciul tot trebuie să pornească. Autentificarea, rutele și DNS rămân sarcina clientului, iar un eșec acolo nu este dovada că intrarea dispozitivului este greșită.

systemd poate adăuga o altă restricție. O unitate cu DeviceAllow sau cu o politică de dispozitive întărită poate refuza accesul la un nod furnizat de administratorul containerelor. Verificați politica de dispozitive a unității când nodul există, dar serviciul raportează o eroare de permisiune, și schimbați acea politică în loc să extindeți containerul.

Conectarea la cald este opțională și explicită. O intrare cu required=false necesită o cale sursă și poate apărea sau dispărea pe măsură ce dispozitivul gazdei se schimbă. Acel ciclu de viață se potrivește hardware-ului care vine și pleacă; pentru un dispozitiv TUN de care VPN-ul are nevoie la pornire, o intrare opțională poate lăsa serviciul să pornească înainte ca precondiția să existe.

Verificați vizibilitatea, deschiderea și interfața în această ordine

Mai întâi confirmați nodul din containerul dorit. Calea, numerele major și minor și proprietatea ar trebui să corespundă dispozitivului gazdei și intrării adăugate. Un nod lipsă înseamnă că administratorul nu a aplicat intrarea sau a aplicat-o pe altă instanță.

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

Apoi confirmați că contul serviciului îl poate deschide. Un test scurt ca acel cont separă o problemă de proprietate de o problemă de serviciu. În final, porniți clientul și confirmați că apare o interfață de tunel; doar acel al treilea pas dovedește întreaga cale, pentru că primele două pot trece în timp ce profilul sau capacitatea clientului sunt încă greșite.

Notați instanța, eticheta dispozitivului, sursa pe gazdă, calea în oaspete și contul proprietar când modificarea este aprobată. Acele cinci valori sunt ceea ce o recreare, migrare sau schimbare de profil ulterioară trebuie să păstreze, și sunt mult mai ușor de comparat decât o eroare de permisiune fără context.