LXD-houer kan nie /dev/net/tun oopmaak nie? Kyk na die unix-char-inskrywing
LXD moet die gasheer se TUN-toestel in die houer deurgee voordat 'n VPN-kliënt dit kan gebruik. Sien wat unix-char byvoeg, wat nie, en hoe om dit te verifieer.
LXD stel 'n gasheer-tekentoestel aan 'n houer bloot deur 'n toestelknooppunt by te voeg, nie deur die gas te leer om een te skep nie. As die houer geen /dev/net/tun het nie, kan die gasheer die toestel hê en die gas kan dit steeds nie oopmaak nie. Die unix-char-inskrywing is die bestuurderkant se helfte van daardie pad, en dit is doelbewus smaller as 'n bevoorregte houer. Daarom verdien die gasheerknooppunt en die houerknooppunt aparte kontroles.
Die meganisme is kort genoeg om in die oog te hou: LXD los 'n gasheerpad op, skep 'n ooreenstemmende knooppunt in die instansie en voeg die toestel by die houer se toestel-cgroup. Die gasproses benodig dan sy eie toestemming en vermoë om die knooppunt vir enigiets te gebruik.
Wat die unix-char-inskrywing werklik verander
'n unix-char-toestel sê vir LXD om een gasheer-tekentoestel op 'n gekose pad in die houer bloot te stel. Die inskrywing het drie dele wat saak maak: die toestelnaam wat die bestuurder gebruik, die source-pad op die gasheer, en die path wat die gas sien. Slegs die laaste twee beskryf die toestel self. 'n Tikkout in enigeen van hulle lewer 'n knooppunt op 'n plek wat die kliënt nooit oopmaak nie.
Op die gasheer is die toestel normaalweg /dev/net/tun. In die houer kan jy dieselfde pad hou of 'n ander kies, maar die pad moet ooreenstem met wat die VPN-kliënt verwag. Om /dev/net/tun te hou vermy 'n tweede konfigurasieprobleem, want die meeste kliënte maak daardie pad oop sonder om te vra.
Die bestuurder pas die inskrywing toe wanneer die instansie begin of wanneer die toestel warm ingeprop word. Dit kopieer nie 'n drywer in die gas nie en dit skep nie 'n tonnelkoppelvlak nie. Dit maak die knooppunt sigbaar en laat toegang toe deur die houer se toestelbeheergroep.
Verklaar die toestel op die instansie, nie in die gas nie
Voeg die inskrywing vanuit die LXD-administrasiekonteks by, met die instansie en 'n etiket wat jy later kan herken. Vir 'n houer genaamd vpnbox is die opdrag:
lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox
Die etiket tun is plaaslik tot die instansiekonfigurasie. Dit is nie 'n koppelvlaknaam nie en dit hoef niks in die gas te pas nie. As 'n profiel reeds dieselfde toestel voorsien, skep 'n tweede inskrywing 'n botsing eerder as oortolligheid, so ondersoek eers die effektiewe konfigurasie.
Om lêers in die houer te wysig is die verkeerde laag. 'n mknod in 'n beginscript kan op 'n bevoorregte houer werk, en dan by herskeping verdwyn of op 'n minder bevoorregte een misluk. Die bestuurder besit die instansie se toestelstel; laat dit ook die knooppunt besit.
Pas eienaarskap en modus by die gasproses aan
Die unix-char-inskrywing kan uid, gid en mode vir die knooppunt in die houer stel. Gebruik hulle om by die rekening te pas wat die VPN-kliënt laat loop, eerder as om die toestel vir elke gebruiker oop te maak of die houer na bevoorregte modus te skakel.
Sigbaarheid is nie dieselfde as toestemming nie. 'n Knooppunt wat deur root besit word met modus 600 is sigbaar vir die diens wat as 'n onbevoorregte gebruiker loop en steeds nie daardeur oopgemaak kan word nie. Kontroleer eers die gasrekening, stel dan die eienaarskap na daardie rekening, en hou die modus nie wyer as wat die kliënt nodig het nie.
Die proses het ook die vermoë nodig om 'n tonnelkoppelvlak te konfigureer, tipies CAP_NET_ADMIN in die houer se netwerknaamruimte. Om die toestel deur te gee verleen nie daardie vermoë nie, en om die vermoë te verleen verskaf nie die toestel nie; hulle is onafhanklike vereistes.
Weet wat die inskrywing nie verleen nie
'n Sigbare knooppunt is nie 'n werkende VPN nie. Die kliëntpakket moet steeds geïnstalleer word, die profiel moet steeds geldig wees, en die diens moet steeds begin. Outentisering, roetes en DNS bly die kliënt se werk, en 'n fout daar is nie bewys dat die toestelinskrywing verkeerd is nie.
systemd kan nog 'n beperking byvoeg. 'n Eenheid met DeviceAllow of 'n verharde toestelbeleid kan toegang weier tot 'n knooppunt wat die houerbestuurder verskaf het. Kontroleer die eenheid se toestelbeleid wanneer die knooppunt bestaan maar die diens 'n toestemmingsfout rapporteer, en verander daardie beleid eerder as om die houer te verbreed.
Warm inprop is opsioneel en eksplisiet. 'n Inskrywing met required=false benodig 'n bronpad en kan verskyn of verdwyn soos die gasheertoestel verander. Daardie lewensiklus pas by hardeware wat kom en gaan; vir 'n TUN-toestel wat die VPN by selflaai nodig het, kan 'n opsionele inskrywing die diens laat begin voordat sy voorvereiste bestaan.
Verifieer sigbaarheid, oopmaak en koppelvlak in daardie volgorde
Bevestig eers die knooppunt in die beoogde houer. Die pad, hoof- en mindergetalle en eienaarskap moet ooreenstem met die gasheertoestel en die inskrywing wat jy bygevoeg het. 'n Ontbrekende knooppunt beteken die bestuurder het die inskrywing nie toegepas nie, of op 'n ander instansie toegepas.
lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'
Bevestig daarna dat die diensrekening dit kan oopmaak. 'n Kort toets as daardie rekening skei 'n eienaarskapprobleem van 'n diensprobleem. Begin laastens die kliënt en bevestig dat 'n tonnelkoppelvlak verskyn; slegs daardie derde stap bewys die hele pad, want die eerste twee kan slaag terwyl die kliëntprofiel of vermoë steeds verkeerd is.
Teken die instansie, toestelnaam, gasheerbron, gaspad en besittende rekening aan wanneer die verandering goedgekeur word. Daardie vyf waardes is wat 'n latere herskeping, migrasie of profielverandering moet bewaar, en hulle is baie makliker om te vergelyk as 'n toestemmingsfout sonder konteks.