OpenVPN sa Docker hindi mabuksan ang /dev/net/tun: ano ang kulang

Ang mga imahe ng container ay maaaring magdala ng bawat OpenVPN binary at configuration file na kailangan nila at mabigo pa rin sa unang tawag sa network. Binabanggit ng error ang /dev/net/tun dahil humingi ang application ng TUN interface sa kernel at ang container ay walang device node o kakayahang gumawa nito. Ito ay dalawang magkahiwalay na pahintulot, at ang pagtatama sa isa ay iniiwan ang isa sa eksaktong kinalalagyan nito.

Ang paghihiwalay sa kanila ay nangangailangan ng isang utos sa bawat isa. Sinasabi ng mensahe ng error pagkatapos kung saang hangganan ka talaga nakatayo.

Ang device node at ang kakayahan ay dalawang pinto

Ang device node ay isang bagay ng filesystem, kaya kailangan itong makita ng container sa sarili nitong mount namespace. Ang kakayahan ay isang pahintulot, kaya kailangan ng proseso ang CAP_NET_ADMIN sa namespace kung saan gagawin ang interface. Ang pagpasa ng device nang walang kakayahan ay nagbibigay ng node na bumubukas at ioctl na nabibigo. Ang pagbibigay ng kakayahan nang walang device ay nag-iiwan sa application na hindi makabukas ng kahit ano, kaya kadalasang lumalabas ang dalawa nang magkasama sa mga halimbawa.

Ang setting na devices ng Docker ay nagmamapa ng device ng host papasok sa container, habang ang cap_add ay nagsasaayos ng set ng kakayahan. Ang bind mount ng parehong landas ay naglalagay ng file sa paningin nang hindi inilalapat ang semantika ng pag-access sa device.

Kopyahin ito sa labas ng file na Compose

Bago i-edit ang serbisyo, tiyakin na may device ang host at kayang gumawa ng interface ang hubad na container. Ang utos sa ibaba ay sadyang minimal, at ang tanging layunin nito ay paghiwalayin ang problema sa host mula sa problema sa compose. Kung mabigo ito, walang pagbabago sa compose ang makakatulong.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

Ang kawalan ng node sa host ay nangangahulugang hindi available ang module ng tun, na pagtatama sa panig ng host at hindi ng container. Ang node na umiiral ngunit hindi mabuksan sa loob ng container ay nagtuturo sa pag-access sa device, at sasabihin ng mensahe ang permission denied sa halip na no such file. Ang pagkakasunod-sunod ng dalawang kabiguang ito ang buong diagnosis. Isulat kung alin ang nakita mo bago baguhin ang anumang flag.

Ang mga error pagkatapos ng TUN ay ibang mga problema

Sa sandaling lumitaw ang interface, may ibang may-ari ang susunod na kabiguan. Ang mga error sa authentication ay nangangahulugang naabot ng tunnel ang server at tinanggihan ang mga kredensyal, kaya hindi makakatulong ang mga pagbabago sa kakayahan. Ang tunnel na nabubuo habang nabibigo pa rin ang mga application ay nagtuturo sa mga ruta, pagpapasa, paglutas ng DNS sa loob ng container, o sa sariling layout ng network ng container. Ang bawat isa sa mga ito ay ordinaryong tanong sa network na hindi masasagot ng pahintulot sa TUN. Ang pag-uulit ng orihinal na pagsubok pagkatapos ng bawat pagbabago ay pumipigil sa mga kabiguan na magsanib sa isang impresyon.

Ang pagkopya ng bawat setting mula sa gumaganang halimbawa ay ang paraan kung paano nagiging hindi mababasang depinisyon ng serbisyo ang isang minimal na pagtatama. Dalhin lamang ang mga kailangan ng deployment na ito at itala kung bakit naroon ang bawat isa.

I-verify ang interface sa loob ng container

Suriin ang interface at ang set ng kakayahan mula sa loob ng tumatakbong container at hindi mula sa host. Ipinapakita ng mga utos sa ibaba ang device node, ang listahan ng kakayahan, at kung may interface na magagawa. Patakbuhin ang mga ito sa parehong container na nagpapatakbo ng client, at i-install ang mga tool kung minimal ang imahe.

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

Ang kakayahang nasa bounding set ngunit wala sa effective set ay kumikilos nang iba kaysa sa isang hindi kailanman ibinigay, at ipinapakita ng capsh ang dalawa. Kung umiiral ang node at naroon ang kakayahan habang nabibigo pa rin ang paggawa, pinipilit ng runtime ang ibang bagay, tulad ng profile ng seccomp o patakaran ng AppArmor na naglilimita sa operasyon. Iyon ay ikatlong hangganan, na dokumentado ng runtime at hindi ng application.

Itala ang mga flag ng container, ang imahe, at ang eksaktong error mula sa bawat pagtatangka. Ang susunod na taong magbabasa ng talaang iyon ay masasabi kung aling pinto ang sarado nang hindi inuulit ang buong imbestigasyon.