OpenVPN en Docker ne povas malfermi /dev/net/tun: kio mankas

Konteneraj bildoj povas porti ĉiun bezonatan OpenVPN-binaran dosieron kaj agordan dosieron kaj tamen malsukcesi ĉe la unua reta voko. La eraro nomas /dev/net/tun ĉar la aplikaĵo petis de la kerno TUN-interfacon kaj la kontenero havis nek la aparatan nodon nek la kapablon krei unu. Tiuj estas du apartaj permesoj, kaj ripari unu lasas la alian ĝuste tie, kie ĝi estis.

Por apartigi ilin necesas po unu komando por ĉiu. La sekva erarmesaĝo diras al vi, ĉe kiu limo vi efektive staris.

La aparata nodo kaj la kapablo estas du pordoj

La aparata nodo estas dosiersistema objekto, do kontenero devas vidi ĝin en sia propra munt-nomspaco. La kapablo estas permeso, do la procezo bezonas CAP_NET_ADMIN en la nomspaco, kie la interfaco estos kreita. Transdoni la aparaton sen la kapablo donas al vi nodon, kiu malfermiĝas, kaj ioctl, kiu malsukcesas. Doni la kapablon sen la aparato lasas la aplikaĵon nekapabla malfermi ion ajn, tial la du kutime aperas kune en ekzemploj.

La agordo devices de Docker mapas la gastigan aparaton en la konteneron, dum cap_add ĝustigas la kapablan aron. Bind mount de la sama vojo metas la dosieron en la vidkampon sen apliki la semantikon de aparata aliro.

Riproduktu ĝin ekster la Compose-dosiero

Antaŭ ol redakti la servon, kontrolu, ĉu la gastiganto havas la aparaton kaj ĉu nuda kontenero povas krei interfacon. La komando sube estas intence minimuma, kaj ĝia sola celo estas apartigi gastigan problemon de compose-problemo. Se ĝi malsukcesas, neniu compose-ŝanĝo helpos.

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'

Mankanta nodo sur la gastiganto signifas, ke la modulo tun ne disponeblas, kio estas riparo flanke de la gastiganto, ne de la kontenero. Nodo, kiu ekzistas sed ne malfermiĝas ene de la kontenero, montras al aparata aliro, kaj la mesaĝo diros permission denied anstataŭ no such file. La ordo de tiuj du malsukcesoj estas la tuta diagnozo. Notu, kiun vi vidis, antaŭ ol ŝanĝi flagon.

La eraroj post TUN estas malsamaj problemoj

Tuj kiam la interfaco aperas, la sekva malsukceso havas alian posedanton. Aŭtentigaj eraroj signifas, ke la tunelo atingis la servilon kaj la akreditaĵoj estis rifuzitaj, do kapablaj ŝanĝoj ne helpos. Tunelo, kiu establiĝas dum aplikaĵoj ankoraŭ malsukcesas, montras al itineroj, plusendo, DNS-rivelado ene de la kontenero aŭ la propra reta aranĝo de la kontenero. Ĉiu el tiuj estas ordinara reta demando, kiun la TUN-permeso ne povas respondi. Ripeti la originalan teston post ĉiu ŝanĝo malhelpas, ke la malsukcesoj fandu sin en unu impreson.

Kopii ĉiun agordon el funkcianta ekzemplo estas la maniero, kiel minimuma riparo fariĝas nelegebla serva difino. Transprenu nur tiujn, kiujn ĉi tiu disfaldado bezonas, kaj notu, kial ĉiu estas tie.

Kontrolu la interfacon ene de la kontenero

Kontrolu la interfacon kaj la kapablan aron de interne de la kuranta kontenero anstataŭ de la gastiganto. La komandoj sube montras la aparatan nodon, la kapablan liston kaj ĉu interfaco entute povas esti kreita. Rulu ilin en la sama kontenero, kiu rulas la klienton, kaj instaligu la ilojn, se la bildo estas minimuma.

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

Kapablo ĉeesta en la bounding set sed foresta el la effective set kondutas malsame ol unu, kiu neniam estis donita, kaj capsh montras ambaŭ. Se la nodo ekzistas kaj la kapablo ĉeestas dum kreado ankoraŭ malsukcesas, la rulmedio devigas ion alian, kiel seccomp-profilo aŭ AppArmor-politiko, kiu limigas la operacion. Tio estas tria limo, dokumentita de la rulmedio anstataŭ de la aplikaĵo.

Notu la kontenerajn flagojn, la bildon kaj la precizan eraron de ĉiu provo. La sekva persono, kiu legos tiun noton, povos diri, kiu pordo estis fermita, sen ripeti la tutan esploron.