OpenVPN i Docker kan ikke åpne /dev/net/tun: hva som mangler

Containerbilder kan inneholde alle OpenVPN-binærfiler og konfigurasjonsfiler de trenger og likevel feile ved det første nettverkskallet. Feilen nevner /dev/net/tun fordi applikasjonen ba kjernen om et TUN-grensesnitt og containeren hadde verken enhetsnoden eller evnen til å opprette en. Dette er to separate tillatelser, og å rette den ene lar den andre bli nøyaktig der den var.

Å skille dem krever én kommando hver. Feilmeldingen etterpå forteller deg hvilken grense du faktisk sto ved.

Enhetsnoden og evnen er to dører

Enhetsnoden er et filsystemobjekt, så en container må se den i sitt eget mount-navnerom. Evnen er en tillatelse, så prosessen trenger CAP_NET_ADMIN i navnerommet der grensesnittet skal opprettes. Å gi enheten videre uten evnen gir deg en node som åpnes og en ioctl som feiler. Å gi evnen uten enheten lar applikasjonen være ute av stand til å åpne noe som helst, og derfor opptrer de to vanligvis sammen i eksempler.

Dockers devices-innstilling mapper vertsenheten inn i containeren, mens cap_add justerer evnesettet. En bind mount av samme sti setter filen i syne uten å anvende semantikk for enhetstilgang.

Gjenskap det utenfor Compose-filen

Før du redigerer tjenesten, kontroller at verten har enheten og at en bar container kan opprette et grensesnitt. Kommandoen nedenfor er bevisst minimal, og dens eneste formål er å skille et vertsproblem fra et compose-problem. Hvis den feiler, hjelper ingen 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'

En manglende node på verten betyr at tun-modulen ikke er tilgjengelig, noe som er en rettelse på vertssiden og ikke i containeren. En node som finnes, men ikke kan åpnes inne i containeren, peker på enhetstilgang, og meldingen vil si permission denied i stedet for no such file. Rekkefølgen av disse to feilene er hele diagnosen. Skriv ned hvilken du så, før du endrer et flagg.

Feilene etter TUN er andre problemer

Så snart grensesnittet dukker opp, har den neste feilen en annen eier. Autentiseringsfeil betyr at tunnelen nådde serveren og at legitimasjonen ble avvist, så endringer i evner hjelper ikke. En tunnel som etableres mens applikasjonene fortsatt feiler, peker på ruter, videresending, DNS-oppslag inne i containeren eller containerens eget nettverksoppsett. Hver av disse er et vanlig nettverksspørsmål som TUN-tillatelsen ikke kan svare på. Å gjenta den opprinnelige testen etter hver endring hindrer feilene i å smelte sammen til ett inntrykk.

Å kopiere hver innstilling fra et fungerende eksempel er måten en minimal rettelse blir en uleselig tjenestedefinisjon. Ta bare med dem denne utrullingen trenger, og noter hvorfor hver av dem er der.

Kontroller grensesnittet inne i containeren

Kontroller grensesnittet og evnesettet innenfra den kjørende containeren i stedet for fra verten. Kommandoene nedenfor viser enhetsnoden, evnelisten og om et grensesnitt i det hele tatt kan opprettes. Kjør dem i den samme containeren som kjører klienten, og installer verktøyene hvis bildet er minimalt.

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

En evne som finnes i bounding set, men mangler i effective set, oppfører seg annerledes enn en som aldri ble gitt, og capsh viser begge. Hvis noden finnes og evnen er der mens opprettelsen fortsatt feiler, håndhever kjøretidsmiljøet noe annet, som en seccomp-profil eller en AppArmor-policy som begrenser operasjonen. Det er en tredje grense, dokumentert av kjøretidsmiljøet og ikke av applikasjonen.

Noter containerens flagg, bildet og den nøyaktige feilen fra hvert forsøk. Den neste personen som leser notatet, kan si hvilken dør som var lukket uten å gjenta hele undersøkelsen.