LXD-container kan ikke åbne /dev/net/tun? Tjek unix-char-posten

LXD eksponerer en tegnenhed fra værten til en container ved at tilføje en enhedsknude, ikke ved at lære gæsten at oprette en. Hvis containeren ikke har /dev/net/tun, kan værten have enheden, og gæsten kan stadig ikke åbne den. unix-char-posten er den halvdel af vejen, der ligger hos administratoren, og den er bevidst snævrere end en privilegeret container. Derfor fortjener værtens knude og containerens knude hver sin kontrol.

Mekanismen er kort nok til at holde øje med: LXD opløser en sti på værten, opretter en tilsvarende knude inde i instansen og føjer enheden til containerens enheds-cgroup. Derefter har gæsteprocessen brug for sin egen tilladelse og evne til at bruge knuden til noget som helst.

Hvad unix-char-posten faktisk ændrer

En unix-char-enhed fortæller LXD at eksponere én tegnenhed fra værten på en valgt sti inde i containeren. Posten har tre dele, der betyder noget: enhedsmærket, som administratoren bruger, stien source på værten og path, som gæsten ser. Kun de to sidste beskriver selve enheden. En tastefejl i en af dem giver en knude på et sted, som klienten aldrig åbner.

På værten er enheden normalt /dev/net/tun. Inde i containeren kan du beholde samme sti eller vælge en anden, men stien skal matche det, VPN-klienten forventer. At beholde /dev/net/tun undgår et andet konfigurationsproblem, fordi de fleste klienter åbner den sti uden at spørge.

Administratoren anvender posten, når instansen starter, eller når enheden hotplugges. Den kopierer ikke en driver ind i gæsten og opretter ikke en tunnelgrænseflade. Den gør knuden synlig og tillader adgang gennem containerens enhedskontrolgruppe.

Deklarer enheden på instansen, ikke inde i gæsten

Tilføj posten fra LXD-administrationskonteksten, og navngiv instansen og et mærke, du kan genkende senere. For en container med navnet vpnbox er kommandoen:

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

Mærket tun er lokalt for instansens konfiguration. Det er ikke et grænsefladenavn og skal ikke matche noget i gæsten. Hvis en profil allerede leverer den samme enhed, skaber en ekstra post en konflikt i stedet for redundans, så undersøg først den effektive konfiguration.

At redigere filer inde i containeren er det forkerte lag. En mknod i et opstartsscript kan se ud til at virke på en privilegeret container og derefter forsvinde ved gendannelse eller fejle på en mindre privilegeret. Administratoren ejer instansens enhedssæt; lad den også eje knuden.

Tilpas ejerskab og tilstand til gæsteprocessen

unix-char-posten kan sætte uid, gid og mode for knuden inde i containeren. Brug dem til at matche den konto, der kører VPN-klienten, i stedet for at åbne enheden for alle brugere eller skifte containeren til privilegeret tilstand.

Synlighed er ikke det samme som tilladelse. En knude ejet af root med tilstand 600 er synlig for tjenesten, der kører som uprivilegeret bruger, og kan stadig ikke åbnes af den. Tjek først gæstekontoen, sæt derefter ejerskabet til den konto, og hold tilstanden ikke bredere, end klienten har brug for.

Processen har også brug for evnen til at konfigurere en tunnelgrænseflade, typisk CAP_NET_ADMIN i containerens netværksnavnerum. At sende enheden videre giver ikke den evne, og at give evnen skaffer ikke enheden; det er uafhængige krav.

Vid, hvad posten ikke giver

En synlig knude er ikke en fungerende VPN. Klientpakken skal stadig installeres, profilen skal stadig være gyldig, og tjenesten skal stadig starte. Godkendelse, ruter og DNS er fortsat klientens arbejde, og en fejl der er ikke bevis for, at enhedsposten er forkert.

systemd kan tilføje en anden begrænsning. En unit med DeviceAllow eller en hærdet enhedspolitik kan nægte adgang til en knude, som containeradministratoren har leveret. Tjek unitens enhedspolitik, når knuden findes, men tjenesten rapporterer en tilladelsesfejl, og ændr den politik i stedet for at udvide containeren.

Hotplug er valgfrit og eksplicit. En post med required=false kræver en kildesti og kan dukke op eller forsvinde, når værtens enhed ændrer sig. Den livscyklus passer til hardware, der kommer og går; for en TUN-enhed, som VPN'en har brug for ved opstart, kan en valgfri post lade tjenesten starte, før dens forudsætning findes.

Verificer synlighed, åbning og grænseflade i den rækkefølge

Bekræft først knuden inde i den tilsigtede container. Stien, hoved- og mindretal og ejerskabet skal matche værtens enhed og den post, du tilføjede. En manglende knude betyder, at administratoren ikke anvendte posten, eller anvendte den på en anden instans.

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

Bekræft derefter, at tjenestekontoen kan åbne den. En kort test som den konto adskiller et ejerskabsproblem fra et tjenesteproblem. Start til sidst klienten, og bekræft, at en tunnelgrænseflade vises; kun det tredje trin beviser hele vejen, fordi de to første kan bestå, mens klientprofilen eller evnen stadig er forkert.

Noter instansen, enhedsmærket, værtens kilde, gæstens sti og den ejende konto, når ændringen godkendes. De fem værdier er det, en senere gendannelse, migrering eller profilændring skal bevare, og de er meget lettere at sammenligne end en tilladelsesfejl uden kontekst.