OpenVPN v Dockerju ne more odpreti /dev/net/tun: kaj manjka

Slike vsebnikov lahko vsebujejo vse potrebne binarne in konfiguracijske datoteke OpenVPN in vseeno spodletijo pri prvem omrežnem klicu. Napaka navaja /dev/net/tun, ker je aplikacija jedru zahtevala vmesnik TUN, vsebnik pa ni imel ne vozlišča naprave ne zmožnosti, da bi ga ustvaril. To sta dve ločeni dovoljenji, in popravilo enega pusti drugo točno tam, kjer je bilo.

Za njuno ločevanje je potreben en ukaz za vsako. Naslednje sporočilo o napaki vam pove, na kateri meji ste dejansko stali.

Vozlišče naprave in zmožnost sta dvoje vrat

Vozlišče naprave je predmet datotečnega sistema, zato ga mora vsebnik videti v svojem lastnem prostoru imen za pripenjanje. Zmožnost je dovoljenje, zato proces potrebuje CAP_NET_ADMIN v prostoru imen, kjer bo vmesnik ustvarjen. Če napravo posredujete brez zmožnosti, dobite vozlišče, ki se odpre, in ioctl, ki spodleti. Če zmožnost dodelite brez naprave, aplikacija ne more odpreti ničesar, zato se oba v primerih običajno pojavita skupaj.

Nastavitev devices v Dockerju preslika gostiteljevo napravo v vsebnik, medtem ko cap_add prilagodi nabor zmožnosti. Bind mount iste poti postavi datoteko v vidno polje, ne da bi uporabil semantiko dostopa do naprave.

To reproducirajte zunaj datoteke Compose

Pred urejanjem storitve preverite, ali ima gostitelj napravo in ali goli vsebnik lahko ustvari vmesnik. Spodnji ukaz je namerno minimalen, njegov edini namen pa je ločiti gostiteljevo težavo od težave compose. Če spodleti, nobena sprememba v compose ne bo pomagala.

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'

Manjkajoče vozlišče na gostitelju pomeni, da modul tun ni na voljo, kar je popravek na strani gostitelja in ne vsebnika. Vozlišče, ki obstaja, a se v vsebniku ne odpre, kaže na dostop do naprave, sporočilo pa bo reklo permission denied namesto no such file. Vrstni red teh dveh neuspehov je celotna diagnoza. Zapišite, katerega ste videli, preden spremenite katero koli zastavico.

Napake po TUN so druge težave

Takoj ko se vmesnik pojavi, ima naslednji neuspeh drugega lastnika. Napake preverjanja pristnosti pomenijo, da je predor dosegel strežnik in so bile poverilnice zavrnjene, zato spremembe zmožnosti ne bodo pomagale. Predor, ki se vzpostavi, medtem ko aplikacije še vedno spodletijo, kaže na poti, posredovanje, razreševanje DNS znotraj vsebnika ali lastno omrežno postavitev vsebnika. Vsaka od teh je običajno omrežno vprašanje, na katero dovoljenje TUN ne more odgovoriti. Ponavljanje prvotnega preskusa po vsaki spremembi prepreči, da bi se neuspehi zlili v en sam vtis.

Kopiranje vsake nastavitve iz delujočega primera je pot, po kateri minimalno popravilo postane neberljiva definicija storitve. Prenesite samo tiste, ki jih ta uvedba potrebuje, in zapišite, zakaj je vsaka tam.

Preverite vmesnik znotraj vsebnika

Preverite vmesnik in nabor zmožnosti od znotraj delujočega vsebnika, ne z gostitelja. Spodnji ukazi prikažejo vozlišče naprave, seznam zmožnosti in ali je vmesnik sploh mogoče ustvariti. Zaženite jih v istem vsebniku, ki izvaja odjemalca, in namestite orodja, če je slika minimalna.

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

Zmožnost, ki je v bounding set, a je v effective set ni, se obnaša drugače kot tista, ki ni bila nikoli dodeljena, in capsh prikaže obe. Če vozlišče obstaja in je zmožnost tam, medtem ko ustvarjanje še vedno spodleti, izvajalno okolje vsiljuje nekaj drugega, na primer profil seccomp ali politiko AppArmor, ki omejuje operacijo. To je tretja meja, ki jo dokumentira izvajalno okolje in ne aplikacija.

Zapišite zastavice vsebnika, sliko in točno napako vsakega poskusa. Naslednja oseba, ki bo prebrala to opombo, bo lahko povedala, katera vrata so bila zaprta, ne da bi ponovila celotno preiskavo.