LXD-container får ikkje opna /dev/net/tun? Sjekk unix-char-oppføringa

LXD eksponerer ei teikneining frå verten til ein container ved å leggja til ein einingknutepunkt, ikkje ved å læra gjesten å laga ein. Viss containeren ikkje har /dev/net/tun, kan verten ha eininga og gjesten likevel ikkje klara å opna henne. unix-char-oppføringa er halvdelen av denne vegen på administratorsida, og ho er medvite smalare enn ein privilegert container. Difor fortener vertsknutepunktet og containerknutepunktet kvar sin kontroll.

Mekanismen er kort nok til å halda i syne: LXD løyser opp ein vertssti, opprettar ein tilsvarande knutepunkt inne i instansen og legg eininga til eining-cgroupen til containeren. Deretter treng gjesteprosessen si eiga løyve og evne for å bruka knutepunktet til noko som helst.

Kva unix-char-oppføringa faktisk endrar

Ei unix-char-eining ber LXD eksponera éi teikneining frå verten på ein vald sti inne i containeren. Oppføringa har tre delar som tyder noko: einingetiketten administratoren brukar, stien source på verten og path som gjesten ser. Berre dei to siste skildrar sjølve eininga. Ein skrivefeil i ein av dei gjev eit knutepunkt på ein stad klienten aldri opnar.

På verten er eininga vanlegvis /dev/net/tun. Inne i containeren kan du halda same sti eller velja ein annan, men stien må samsvara med det VPN-klienten ventar. Å halda /dev/net/tun unngår eit andre konfigurasjonsproblem, fordi dei fleste klientar opnar den stien utan å spørja.

Administratoren brukar oppføringa når instansen startar eller når eininga blir kopla til medan han køyrer. Ho kopierer ikkje ein drivar inn i gjesten og opprettar ikkje eit tunnegrensesnitt. Ho gjer knutepunktet synleg og lèt tilgang gjennom einingkontrollgruppa til containeren.

Erklær eininga på instansen, ikkje inne i gjesten

Legg til oppføringa frå LXD-administrasjonskonteksten, og namnge instansen og ein etikett du kjenner att seinare. For ein container som heiter 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 konfigurasjonen til instansen. Han er ikkje eit grensesnittnamn og treng ikkje samsvara med noko i gjesten. Viss ein profil alt leverer same eininga, skapar ei ekstra oppføring ein konflikt i staden for redundans, så gransk den effektive konfigurasjonen først.

Å redigera filer inne i containeren er feil lag. Ein mknod i eit oppstartsskript kan sjå ut til å verka på ein privilegert container, og deretter forsvinna ved gjenoppretting eller mislukkast på ein mindre privilegert. Administratoren eig einingesettet til instansen; la han òg eiga knutepunktet.

Tilpass eigarskap og modus til gjesteprosessen

unix-char-oppføringa kan setja uid, gid og mode for knutepunktet inne i containeren. Bruk dei til å samsvara med kontoen som køyrer VPN-klienten, i staden for å opna eininga for alle brukarar eller byta containeren til privilegert modus.

Synlegheit er ikkje det same som løyve. Eit knutepunkt eigd av root med modus 600 er synleg for tenesta som køyrer som uprivilegert brukar, og kan likevel ikkje opnast av henne. Sjekk gjestekontoen først, set deretter eigarskapen til den kontoen, og hald modusen ikkje breiare enn klienten treng.

Prosessen treng òg evna til å konfigurera eit tunnegrensesnitt, vanlegvis CAP_NET_ADMIN i nettverksnamnerommet til containeren. Å senda eininga vidare gjev ikkje den evna, og å gje evna skaffar ikkje eininga; dette er uavhengige krav.

Vit kva oppføringa ikkje gjev

Eit synleg knutepunkt er ikkje ein fungerande VPN. Klientpakken må framleis installerast, profilen må framleis vera gyldig, og tenesta må framleis starta. Autentisering, ruter og DNS er framleis arbeidet til klienten, og ein feil der er ikkje prov for at einingoppføringa er feil.

systemd kan leggja til ei anna avgrensing. Ei eining med DeviceAllow eller ein herda einingepolitikk kan nekta tilgang til eit knutepunkt som containeradministratoren har levert. Sjekk einingepolitikken når knutepunktet finst, men tenesta rapporterer ein løyvefeil, og endra den politikken i staden for å utvida containeren.

Varm tilkopling er valfri og eksplisitt. Ei oppføring med required=false treng ein kjedesti og kan dukka opp eller forsvinna når vertseininga endrar seg. Den livssyklusen passar for maskinvare som kjem og går; for ei TUN-eining som VPN-et treng ved oppstart, kan ei valfri oppføring la tenesta starta før føresetnaden finst.

Stadfest synlegheit, opning og grensesnitt i den rekkjefølgja

Stadfest først knutepunktet inne i den tiltenkte containeren. Stien, hovud- og mindretalet og eigarskapen skal samsvara med vertseininga og oppføringa du la til. Eit manglande knutepunkt tyder at administratoren ikkje brukte oppføringa, eller brukte henne på ein annan instans.

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

Stadfest deretter at tenestekontoen kan opna henne. Ein kort test som den kontoen skil eit eigarskapsproblem frå eit tenesteproblem. Start til slutt klienten og stadfest at eit tunnegrensesnitt dukkar opp; berre det tredje trinnet provar heile vegen, fordi dei to første kan bestå medan klientprofilen eller evna framleis er feil.

Noter instansen, einingetiketten, vertskjelda, gjestestien og den eigande kontoen når endringa blir godkjend. Dei fem verdiane er det ein seinare gjenoppretting, migrering eller profilendring må vara på, og dei er mykje lettare å samanlikna enn ein løyvefeil utan kontekst.