LXD-container får ikke åpnet /dev/net/tun? Sjekk unix-char-oppføringen

LXD eksponerer en tegnenhet fra verten til en container ved å legge til en enhetsnode, ikke ved å lære gjesten å opprette en. Hvis containeren ikke har /dev/net/tun, kan verten ha enheten og gjesten likevel ikke klare å åpne den. unix-char-oppføringen er halvdelen av denne veien på administratorens side, og den er bevisst smalere enn en privilegert container. Derfor fortjener vertsnode og containernode hver sin kontroll.

Mekanismen er kort nok til å holde i syne: LXD løser opp en vertssti, oppretter en tilsvarende node inne i instansen og legger enheten til containerens enhets-cgroup. Deretter trenger gjesteprosessen sin egen tillatelse og evne for å bruke noden til noe som helst.

Hva unix-char-oppføringen faktisk endrer

En unix-char-enhet ber LXD eksponere én tegnenhet fra verten på en valgt sti inne i containeren. Oppføringen har tre deler som betyr noe: enhetsetiketten administratoren bruker, stien source på verten og path som gjesten ser. Bare de to siste beskriver selve enheten. En skrivefeil i en av dem gir en node på et sted klienten aldri åpner.

På verten er enheten vanligvis /dev/net/tun. Inne i containeren kan du beholde samme sti eller velge en annen, men stien må samsvare med det VPN-klienten forventer. Å beholde /dev/net/tun unngår et andre konfigurasjonsproblem, fordi de fleste klienter åpner den stien uten å spørre.

Administratoren bruker oppføringen når instansen starter eller når enheten kobles til mens den kjører. Den kopierer ikke en driver inn i gjesten og oppretter ikke et tunnelgrensesnitt. Den gjør noden synlig og tillater tilgang gjennom containerens enhetskontrollgruppe.

Erklær enheten på instansen, ikke inne i gjesten

Legg til oppføringen fra LXD-administrasjonskonteksten, og navngi instansen og en etikett du kjenner igjen senere. For en container som heter vpnbox er kommandoen:

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

Etiketten tun er lokal for instansens konfigurasjon. Den er ikke et grensesnittnavn og trenger ikke samsvare med noe i gjesten. Hvis en profil allerede leverer samme enhet, skaper en ekstra oppføring en konflikt i stedet for redundans, så undersøk den effektive konfigurasjonen først.

Å redigere filer inne i containeren er feil lag. En mknod i et oppstartsskript kan se ut til å virke på en privilegert container, og deretter forsvinne ved gjenoppretting eller feile på en mindre privilegert. Administratoren eier instansens enhetssett; la den også eie noden.

Tilpass eierskap og modus til gjesteprosessen

unix-char-oppføringen kan sette uid, gid og mode for noden inne i containeren. Bruk dem til å samsvare med kontoen som kjører VPN-klienten, i stedet for å åpne enheten for alle brukere eller bytte containeren til privilegert modus.

Synlighet er ikke det samme som tillatelse. En node eid av root med modus 600 er synlig for tjenesten som kjører som uprivilegert bruker, og kan likevel ikke åpnes av den. Sjekk gjestekontoen først, sett deretter eierskapet til den kontoen, og hold modusen ikke bredere enn klienten trenger.

Prosessen trenger også evnen til å konfigurere et tunnelgrensesnitt, vanligvis CAP_NET_ADMIN i containerens nettverksnavnerom. Å sende enheten videre gir ikke den evnen, og å gi evnen skaffer ikke enheten; dette er uavhengige krav.

Vit hva oppføringen ikke gir

En synlig node er ikke en fungerende VPN. Klientpakken må fortsatt installeres, profilen må fortsatt være gyldig, og tjenesten må fortsatt starte. Autentisering, ruter og DNS er fortsatt klientens arbeid, og en feil der er ikke bevis for at enhetsoppføringen er feil.

systemd kan legge til en annen begrensning. En enhet med DeviceAllow eller en herdet enhetspolicy kan nekte tilgang til en node som containeradministratoren har levert. Sjekk enhetens enhetspolicy når noden finnes, men tjenesten rapporterer en tillatelsesfeil, og endre den policyen i stedet for å utvide containeren.

Varm tilkobling er valgfri og eksplisitt. En oppføring med required=false trenger en kildesti og kan dukke opp eller forsvinne når vertsenheten endres. Den livssyklusen passer for maskinvare som kommer og går; for en TUN-enhet som VPN-et trenger ved oppstart, kan en valgfri oppføring la tjenesten starte før forutsetningen finnes.

Verifiser synlighet, åpning og grensesnitt i den rekkefølgen

Bekreft først noden inne i den tiltenkte containeren. Stien, hoved- og mindretallet og eierskapet skal samsvare med vertsenheten og oppføringen du la til. En manglende node betyr at administratoren ikke brukte oppføringen, eller brukte den på en annen instans.

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

Bekreft deretter at tjenestekontoen kan åpne den. En kort test som den kontoen skiller et eierskapsproblem fra et tjenesteproblem. Start til slutt klienten og bekreft at et tunnelgrensesnitt dukker opp; bare det tredje trinnet beviser hele veien, fordi de to første kan bestå mens klientprofilen eller evnen fortsatt er feil.

Noter instansen, enhetsetiketten, vertskilden, gjestestien og den eierende kontoen når endringen godkjennes. De fem verdiene er det en senere gjenoppretting, migrering eller profilendring må bevare, og de er mye lettere å sammenligne enn en tillatelsesfeil uten kontekst.