OpenVPN i Docker kan ikkje opne /dev/net/tun: kva som manglar

Containerbilete kan innehalde alle OpenVPN-binærfiler og konfigurasjonsfiler dei treng og likevel feile ved det første nettverkskallet. Feilen nemner /dev/net/tun fordi applikasjonen bad kjernen om eit TUN-grensesnitt og containeren hadde korkje eininga si node eller evna til å opprette ei. Dette er to separate løyve, og å rette den eine lèt den andre bli nøyaktig der han var.

Å skilje dei krev éin kommando kvar. Feilmeldinga etterpå fortel deg kva grense du faktisk stod ved.

Eininga si node og evna er to dører

Eininga si node er eit filsystemobjekt, så ein container må sjå henne i sitt eige mount-namnerom. Evna er eit løyve, så prosessen treng CAP_NET_ADMIN i namnerommet der grensesnittet skal opprettast. Å gje eininga vidare utan evna gjev deg ein node som opnast og ein ioctl som feilar. Å gje evna utan eininga lèt applikasjonen vere ute av stand til å opne noko som helst, og difor opptrer dei to vanlegvis saman i døme.

Dockers devices-innstilling mappar vertseininga inn i containeren, medan cap_add justerer evnesettet. Ein bind mount av same sti set fila i syne utan å bruke semantikk for einingstilgang.

Gjenskap det utanfor Compose-fila

Før du redigerer tenesta, kontroller at verten har eininga og at ein bar container kan opprette eit grensesnitt. Kommandoen nedanfor er medvite minimal, og det einaste føremålet er å skilje eit vertsproblem frå eit compose-problem. Viss han feilar, hjelper inga compose-endring.

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'

Ein manglande node på verten tyder at tun-modulen ikkje er tilgjengeleg, noko som er ei retting på vertssida og ikkje i containeren. Ein node som finst, men ikkje kan opnast inne i containeren, peikar på einingstilgang, og meldinga vil seie permission denied i staden for no such file. Rekkefølgja av desse to feila er heile diagnosen. Skriv ned kva du såg, før du endrar eit flagg.

Feila etter TUN er andre problem

Så snart grensesnittet dukkar opp, har den neste feilen ein annan eigar. Autentiseringsfeil tyder at tunnelen nådde tenaren og at påloggingsdetaljane vart avviste, så endringar i evner hjelper ikkje. Ein tunnel som etablerast medan applikasjonane framleis feilar, peikar på ruter, vidaresending, DNS-oppslag inne i containeren eller containeren sitt eige nettverksoppsett. Kvart av desse er eit vanleg nettverksspørsmål som TUN-løyvet ikkje kan svare på. Å gjenta den opphavlege testen etter kvar endring hindrar feila i å smelte saman til eitt inntrykk.

Å kopiere kvar innstilling frå eit fungerande døme er måten ei minimal retting blir ein uleseleg tenestedefinisjon. Ta berre med dei denne utrullinga treng, og noter kvifor kvar av dei er der.

Kontroller grensesnittet inne i containeren

Kontroller grensesnittet og evnesettet innanfrå den køyrande containeren i staden for frå verten. Kommandoane nedanfor viser eininga si node, evnelista og om eit grensesnitt i det heile kan opprettast. Køyr dei i den same containeren som køyrer klienten, og installer verktøya viss biletet er minimalt.

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

Ei evne som finst i bounding set, men manglar i effective set, oppfører seg annleis enn ei som aldri vart gjeven, og capsh viser begge. Viss noden finst og evna er der medan opprettinga framleis feilar, handhevar køyretidsmiljøet noko anna, som ein seccomp-profil eller ein AppArmor-policy som avgrensar operasjonen. Det er ei tredje grense, dokumentert av køyretidsmiljøet og ikkje av applikasjonen.

Noter flagga til containeren, biletet og den nøyaktige feilen frå kvart forsøk. Den neste personen som les notatet, kan seie kva dør som var lukka utan å gjenta heile undersøkinga.