LXD-container opent /dev/net/tun niet? Controleer de unix-char-regel

LXD stelt een tekenapparaat van de host beschikbaar aan een container door een apparaatknooppunt toe te voegen, niet door de gast te leren er een te maken. Heeft de container geen /dev/net/tun, dan kan de host het apparaat hebben en de gast het alsnog niet kunnen openen. De unix-char-regel is de beheerdershelft van dat pad, en hij is bewust smaller dan een geprivilegieerde container. Daarom verdienen het hostknooppunt en het containerknooppunt aparte controles.

Het mechanisme is kort genoeg om in het oog te houden: LXD lost een hostpad op, maakt een overeenkomend knooppunt in de instantie en voegt het apparaat toe aan de apparaat-cgroup van de container. Daarna heeft het gastproces zijn eigen toestemming en vermogen nodig om het knooppunt ergens voor te gebruiken.

Wat de unix-char-regel werkelijk verandert

Een unix-char-apparaat vertelt LXD om één tekenapparaat van de host op een gekozen pad in de container beschikbaar te stellen. De regel heeft drie delen die ertoe doen: het apparaatlabel dat de beheerder gebruikt, het pad source op de host en het path dat de gast ziet. Alleen de laatste twee beschrijven het apparaat zelf. Een typefout in een van beide levert een knooppunt op een plek die de client nooit opent.

Op de host is het apparaat meestal /dev/net/tun. In de container kunt u hetzelfde pad houden of een ander kiezen, maar het pad moet overeenkomen met wat de VPN-client verwacht. /dev/net/tun houden voorkomt een tweede configuratieprobleem, omdat de meeste clients dat pad zonder vragen openen.

De beheerder past de regel toe wanneer de instantie start of wanneer het apparaat heet wordt aangesloten. Hij kopieert geen stuurprogramma naar de gast en maakt geen tunnelinterface. Hij maakt het knooppunt zichtbaar en staat toegang toe via de apparaatcontrolegroep van de container.

Verklaar het apparaat op de instantie, niet in de gast

Voeg de regel toe vanuit de LXD-beheercontext, met de instantie en een label dat u later herkent. Voor een container met de naam vpnbox is de opdracht:

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

Het label tun is lokaal voor de configuratie van de instantie. Het is geen interfacenaam en het hoeft nergens in de gast mee overeen te komen. Levert een profiel hetzelfde apparaat al, dan maakt een tweede regel een conflict in plaats van redundantie, dus bekijk eerst de effectieve configuratie.

Bestanden in de container bewerken is de verkeerde laag. Een mknod in een startscript kan op een geprivilegieerde container lijken te werken en daarna verdwijnen bij hernieuwde aanmaak of falen op een minder geprivilegieerde. De beheerder bezit de apparatenset van de instantie; laat hem ook het knooppunt bezitten.

Stem eigendom en modus af op het gastproces

De unix-char-regel kan uid, gid en mode instellen voor het knooppunt in de container. Gebruik ze om aan te sluiten bij het account dat de VPN-client uitvoert, in plaats van het apparaat voor iedere gebruiker te openen of de container naar geprivilegieerde modus te zetten.

Zichtbaarheid is niet hetzelfde als toestemming. Een knooppunt in eigendom van root met modus 600 is zichtbaar voor de dienst die als onbevoorrechte gebruiker draait en is er toch niet door te openen. Controleer eerst het gastaccount, stel daarna het eigendom in op dat account en houd de modus niet ruimer dan de client nodig heeft.

Het proces heeft ook het vermogen nodig om een tunnelinterface te configureren, meestal CAP_NET_ADMIN in de netwerknaamruimte van de container. Het apparaat doorgeven verleent dat vermogen niet, en het vermogen verlenen levert het apparaat niet; het zijn onafhankelijke vereisten.

Weet wat de regel niet verleent

Een zichtbaar knooppunt is geen werkende VPN. Het clientpakket moet nog worden geïnstalleerd, het profiel moet nog geldig zijn en de dienst moet nog starten. Authenticatie, routes en DNS blijven werk van de client, en een fout daar is geen bewijs dat de apparaatregel onjuist is.

systemd kan nog een beperking toevoegen. Een unit met DeviceAllow of een gehard apparaatbeleid kan toegang weigeren tot een knooppunt dat de containerbeheerder heeft geleverd. Controleer het apparaatbeleid van de unit wanneer het knooppunt bestaat maar de dienst een toestemmingsfout meldt, en wijzig dat beleid in plaats van de container te verbreden.

Heet aansluiten is optioneel en expliciet. Een regel met required=false vereist een bronpad en kan verschijnen of verdwijnen wanneer het hostapparaat verandert. Die levenscyclus past bij hardware die komt en gaat; voor een TUN-apparaat dat de VPN bij het opstarten nodig heeft, kan een optionele regel de dienst laten starten voordat de voorwaarde bestaat.

Controleer zichtbaarheid, openen en interface in die volgorde

Bevestig eerst het knooppunt in de bedoelde container. Het pad, de major- en minornummers en het eigendom moeten overeenkomen met het hostapparaat en de regel die u hebt toegevoegd. Een ontbrekend knooppunt betekent dat de beheerder de regel niet heeft toegepast, of op een andere instantie heeft toegepast.

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 het dienstaccount het kan openen. Een korte test als dat account scheidt een eigendomsprobleem van een dienstprobleem. Start ten slotte de client en bevestig dat er een tunnelinterface verschijnt; alleen die derde stap bewijst het hele pad, omdat de eerste twee kunnen slagen terwijl het clientprofiel of het vermogen nog onjuist is.

Noteer de instantie, het apparaatlabel, de hostbron, het gastpad en het eigenaarsaccount wanneer de wijziging wordt goedgekeurd. Die vijf waarden zijn wat een latere hernieuwde aanmaak, migratie of profielwijziging moet behouden, en ze zijn veel gemakkelijker te vergelijken dan een toestemmingsfout zonder context.