Hindi mabuksan ng container ng LXD ang /dev/net/tun? Suriin ang entry na unix-char

Inilalantad ng LXD ang character device ng host sa container sa pamamagitan ng pagdaragdag ng device node, hindi sa pagtuturo sa bisita na gumawa nito. Kung walang /dev/net/tun ang container, maaaring nasa host ang device at hindi pa rin ito mabubuksan ng bisita. Ang entry na unix-char ay ang kalahati ng landasing iyon sa panig ng tagapangasiwa, at sadyang mas makitid ito kaysa sa isang privileged container. Kaya ang node ng host at ang node ng container ay karapat-dapat sa magkahiwalay na pagsusuri.

Ang mekanismo ay sapat na maikli upang manatili sa paningin: nilulutas ng LXD ang isang landas sa host, gumagawa ng katumbas na node sa loob ng instance at idinadagdag ang device sa cgroup ng mga device ng container. Pagkatapos, kailangan ng proseso ng bisita ang sarili nitong pahintulot at kakayahan upang magamit ang node sa kahit ano.

Ano ang talagang binabago ng entry na unix-char

Sinasabi ng isang unix-char device sa LXD na ilantad ang isang character device ng host sa isang piniling landas sa loob ng container. May tatlong mahalagang bahagi ang entry: ang label ng device na ginagamit ng tagapangasiwa, ang landas na source sa host at ang path na nakikita ng bisita. Ang huling dalawa lamang ang naglalarawan sa device mismo. Ang isang maling uri sa alinman sa mga ito ay gumagawa ng node sa lugar na hindi kailanman binubuksan ng client.

Sa host, ang device ay karaniwang /dev/net/tun. Sa loob ng container maaari mong panatilihin ang parehong landas o pumili ng iba, ngunit dapat tumugma ang landas sa inaasahan ng VPN client. Ang pagpapanatili ng /dev/net/tun ay umiiwas sa pangalawang problema sa pagsasaayos, dahil binubuksan ng karamihan ng client ang landas na iyon nang walang tanong.

Inilalapat ng tagapangasiwa ang entry kapag nagsimula ang instance o kapag mainit na ikinonekta ang device. Hindi ito kumokopya ng driver sa bisita at hindi ito gumagawa ng tunnel interface. Ginagawa nitong nakikita ang node at pinapayagan ang pag-access sa pamamagitan ng control group ng mga device ng container.

Ipahayag ang device sa instance, hindi sa loob ng bisita

Idagdag ang entry mula sa konteksto ng pangangasiwa ng LXD, na pinapangalanan ang instance at isang label na makikilala mo mamaya. Para sa container na tinatawag na vpnbox, ang utos ay:

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

Ang label na tun ay lokal sa pagsasaayos ng instance. Hindi ito pangalan ng interface at hindi kailangang tumugma sa anuman sa bisita. Kung may profile na nagbibigay na ng parehong device, ang pagdaragdag ng pangalawang entry ay gumagawa ng salungatan at hindi kalabisan, kaya suriin muna ang epektibong pagsasaayos.

Ang pag-edit ng mga file sa loob ng container ay maling antas. Ang mknod sa isang startup script ay maaaring magmukhang gumagana sa privileged container, pagkatapos ay mawala sa muling paglikha o mabigo sa isang hindi gaanong privileged. Pag-aari ng tagapangasiwa ang set ng device ng instance; hayaan siyang magmay-ari din ng node.

Itugma ang pagmamay-ari at mode sa proseso ng bisita

Maaaring itakda ng entry na unix-char ang uid, gid at mode para sa node sa loob ng container. Gamitin ang mga ito upang tumugma sa account na nagpapatakbo ng VPN client, sa halip na buksan ang device sa lahat ng user o ilipat ang container sa privileged mode.

Ang pagiging nakikita ay hindi katulad ng pahintulot. Ang node na pag-aari ng root na may mode 600 ay nakikita ng serbisyong tumatakbo bilang walang pribilehiyong user at hindi pa rin ito mabubuksan nito. Suriin muna ang account ng bisita, pagkatapos itakda ang pagmamay-ari sa account na iyon, at panatilihing hindi mas malawak ang mode kaysa kailangan ng client.

Kailangan din ng proseso ng kakayahang i-configure ang isang tunnel interface, karaniwang CAP_NET_ADMIN sa network namespace ng container. Ang pagpasa ng device ay hindi nagbibigay ng kakayahang iyon, at ang pagbibigay ng kakayahan ay hindi nagbibigay ng device; magkahiwalay na pangangailangan ang mga ito.

Alamin kung ano ang hindi ibinibigay ng entry

Ang nakikitang node ay hindi isang gumaganang VPN. Kailangan pa ring i-install ang client package, kailangan pa ring valid ang profile, at kailangan pa ring magsimula ang serbisyo. Ang authentication, ruta at DNS ay nananatiling trabaho ng client, at ang kabiguan doon ay hindi patunay na mali ang entry ng device.

Maaaring magdagdag ang systemd ng isa pang paghihigpit. Ang isang unit na may DeviceAllow o pinatigas na patakaran sa device ay maaaring tumanggi sa pag-access sa node na ibinigay ng tagapangasiwa ng container. Suriin ang patakaran sa device ng unit kapag umiiral ang node ngunit nag-uulat ang serbisyo ng error sa pahintulot, at baguhin ang patakarang iyon sa halip na palawakin ang container.

Ang hotplug ay opsyonal at tahasan. Ang entry na may required=false ay nangangailangan ng source path at maaaring lumitaw o mawala habang nagbabago ang device ng host. Ang ganitong lifecycle ay bagay sa hardware na dumarating at umaalis; para sa TUN device na kailangan ng VPN sa boot, ang opsyonal na entry ay maaaring hayaang magsimula ang serbisyo bago umiiral ang paunang kundisyon nito.

Beripikahin ang pagiging nakikita, pagbubukas at interface sa ganoong pagkakasunod-sunod

Unang kumpirmahin ang node sa loob ng nilalayong container. Ang landas, major at minor na numero at pagmamay-ari ay dapat tumugma sa device ng host at sa entry na idinagdag mo. Ang nawawalang node ay nangangahulugang hindi inilapat ng tagapangasiwa ang entry, o inilapat ito sa ibang instance.

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

Pagkatapos, kumpirmahin na mabubuksan ito ng account ng serbisyo. Ang maikling pagsubok bilang account na iyon ay naghihiwalay ng problema sa pagmamay-ari mula sa problema sa serbisyo. Sa huli, simulan ang client at kumpirmahin na lumilitaw ang isang tunnel interface; tanging ang ikatlong hakbang na iyon ang nagpapatunay sa buong landas, dahil ang unang dalawa ay maaaring pumasa habang mali pa rin ang profile o kakayahan ng client.

Itala ang instance, label ng device, pinagmulan sa host, landas sa bisita at account na may-ari kapag naaprubahan ang pagbabago. Ang limang halagang iyon ang kailangang pangalagaan ng muling paglikha, migrasyon o pagbabago ng profile sa hinaharap, at mas madaling ihambing ang mga ito kaysa sa error sa pahintulot na walang konteksto.