OpenVPN i Docker kan ikke åbne /dev/net/tun: hvad der mangler

Containerbilleder kan indeholde alle de OpenVPN-binærfiler og konfigurationsfiler, de har brug for, og alligevel fejle ved det første netværkskald. Fejlen nævner /dev/net/tun, fordi programmet bad kernen om et TUN-interface, og containeren havde hverken enhedsnoden eller evnen til at oprette en. Det er to separate tilladelser, og når man retter den ene, bliver den anden præcis, hvor den var.

At skille dem ad kræver én kommando hver. Fejlmeddelelsen bagefter fortæller dig, hvilken grænse du rent faktisk stod ved.

Enhedsnoden og evnen er to døre

Enhedsnoden er et filsystemobjekt, så en container skal kunne se den i sit eget mount-namespace. Evnen er en tilladelse, så processen har brug for CAP_NET_ADMIN i det namespace, hvor interfacet skal oprettes. At give enheden videre uden evnen giver dig en node, der åbner, og en ioctl, der fejler. At give evnen uden enheden efterlader programmet ude af stand til at åbne noget som helst, og derfor optræder de to normalt sammen i eksempler.

Dockers devices-indstilling mapper værtsenheden ind i containeren, mens cap_add justerer evnesættet. En bind mount af samme sti sætter filen i syne uden at anvende semantik for enhedsadgang.

Genskab det uden for Compose-filen

Før du redigerer tjenesten, skal du kontrollere, at værten har enheden, og at en bar container kan oprette et interface. Kommandoen nedenfor er bevidst minimal, og dens eneste formål er at skille et værtsproblem fra et compose-problem. Hvis den fejler, hjælper ingen compose-ændring.

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å værten betyder, at tun-modulet ikke er tilgængeligt, hvilket er en rettelse på værtsiden frem for i containeren. En node, der findes, men ikke kan åbnes inde i containeren, peger på enhedsadgang, og meddelelsen vil sige permission denied i stedet for no such file. Rækkefølgen af de to fejl er hele diagnosen. Skriv ned, hvilken du så, før du ændrer et flag.

Fejlene efter TUN er andre problemer

Når interfacet dukker op, har den næste fejl en anden ejer. Godkendelsesfejl betyder, at tunnelen nåede serveren, og at legitimationsoplysningerne blev afvist, så ændringer i evner hjælper ikke. En tunnel, der etableres, mens programmer stadig fejler, peger på ruter, videresendelse, DNS-opløsning inde i containeren eller containerens eget netværkslayout. Hver af disse er et almindeligt netværksspørgsmål, som TUN-tilladelsen ikke kan besvare. At gentage den oprindelige test efter hver ændring forhindrer, at fejlene smelter sammen til ét indtryk.

At kopiere hver indstilling fra et fungerende eksempel er måden, hvorpå en minimal rettelse bliver en ulæselig tjenestedefinition. Tag kun dem med, som denne udrulning har brug for, og noter, hvorfor hver enkelt er der.

Kontroller interfacet inde i containeren

Kontroller interfacet og evnesættet inde fra den kørende container i stedet for fra værten. Kommandoerne nedenfor viser enhedsnoden, evnelisten og hvorvidt et interface overhovedet kan oprettes. Kør dem i den samme container, der kører klienten, og installér værktøjerne, hvis billedet 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, der findes i bounding set, men mangler i effective set, opfører sig anderledes end en, der aldrig blev givet, og capsh viser begge. Hvis noden findes, og evnen er der, mens oprettelsen stadig fejler, håndhæver runtime noget andet, såsom en seccomp-profil eller en AppArmor-politik, der begrænser handlingen. Det er en tredje grænse, dokumenteret af runtime frem for af programmet.

Noter containerens flag, billedet og den præcise fejl fra hvert forsøg. Den næste person, der læser den note, kan se, hvilken dør der var lukket, uden at gentage hele undersøgelsen.