OpenVPN v Dockeri nedokáže otvoriť /dev/net/tun: čo chýba

Kontajnerové obrazy môžu obsahovať všetky potrebné binárne a konfiguračné súbory OpenVPN a napriek tomu zlyhať pri prvom sieťovom volaní. Chyba uvádza /dev/net/tun, pretože aplikácia požiadala jadro o rozhranie TUN a kontajner nemal ani uzol zariadenia, ani schopnosť ho vytvoriť. Sú to dve oddelené povolenia a oprava jedného nechá druhé presne tam, kde bolo.

Ich oddelenie si vyžaduje jeden príkaz pre každé. Nasledujúca chybová správa vám povie, na ktorej hranici ste skutočne stáli.

Uzol zariadenia a schopnosť sú dvoje dvere

Uzol zariadenia je objekt súborového systému, takže ho kontajner musí vidieť vo svojom vlastnom mennom priestore pripojenia. Schopnosť je povolenie, takže proces potrebuje CAP_NET_ADMIN v mennom priestore, kde bude rozhranie vytvorené. Odovzdanie zariadenia bez schopnosti vám dá uzol, ktorý sa otvorí, a ioctl, ktorý zlyhá. Udelenie schopnosti bez zariadenia nechá aplikáciu neschopnú otvoriť čokoľvek, a preto sa obe v príkladoch zvyčajne objavujú spolu.

Nastavenie devices v Dockeri mapuje zariadenie hostiteľa do kontajnera, zatiaľ čo cap_add upravuje množinu schopností. Bind mount tej istej cesty umiestni súbor do zorného poľa bez uplatnenia sémantiky prístupu k zariadeniu.

Reprodukujte to mimo súboru Compose

Pred úpravou služby overte, že hostiteľ má zariadenie a že holý kontajner dokáže vytvoriť rozhranie. Nižšie uvedený príkaz je zámerne minimálny a jeho jediným účelom je oddeliť problém hostiteľa od problému compose. Ak zlyhá, žiadna zmena v compose nepomôže.

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'

Chýbajúci uzol na hostiteľovi znamená, že modul tun nie je dostupný, čo je oprava na strane hostiteľa, nie kontajnera. Uzol, ktorý existuje, ale v kontajneri sa nedá otvoriť, poukazuje na prístup k zariadeniu a správa povie permission denied namiesto no such file. Poradie týchto dvoch zlyhaní je celá diagnóza. Zapíšte si, ktoré ste videli, skôr než zmeníte akýkoľvek príznak.

Chyby po TUN sú iné problémy

Hneď ako sa rozhranie objaví, má ďalšie zlyhanie iného vlastníka. Chyby overovania znamenajú, že tunel dosiahol server a prihlasovacie údaje boli odmietnuté, takže zmeny schopností nepomôžu. Tunel, ktorý sa nadviaže, zatiaľ čo aplikácie stále zlyhávajú, poukazuje na trasy, preposielanie, preklad DNS vnútri kontajnera alebo vlastné sieťové usporiadanie kontajnera. Každé z toho je bežná sieťová otázka, na ktorú povolenie TUN nedokáže odpovedať. Opakovanie pôvodného testu po každej zmene bráni tomu, aby sa zlyhania zliali do jedného dojmu.

Kopírovanie každého nastavenia z funkčného príkladu je spôsob, akým sa z minimálnej opravy stane nečitateľná definícia služby. Preneste len tie, ktoré toto nasadenie potrebuje, a poznamenajte, prečo je každé tam.

Overte rozhranie vnútri kontajnera

Skontrolujte rozhranie a množinu schopností zvnútra bežiaceho kontajnera, nie z hostiteľa. Nižšie uvedené príkazy ukazujú uzol zariadenia, zoznam schopností a či sa rozhranie vôbec dá vytvoriť. Spustite ich v tom istom kontajneri, ktorý spúšťa klienta, a nainštalujte nástroje, ak je obraz minimálny.

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

Schopnosť prítomná v bounding set, ale chýbajúca v effective set, sa správa inak ako tá, ktorá nikdy nebola udelená, a capsh ukazuje obe. Ak uzol existuje a schopnosť je k dispozícii, zatiaľ čo vytváranie stále zlyháva, runtime presadzuje niečo iné, napríklad profil seccomp alebo pravidlo AppArmor, ktoré operáciu obmedzuje. To je tretia hranica, ktorú dokumentuje runtime, nie aplikácia.

Zapíšte príznaky kontajnera, obraz a presnú chybu každého pokusu. Ďalší človek, ktorý si túto poznámku prečíta, bude vedieť povedať, ktoré dvere boli zatvorené, bez opakovania celého vyšetrovania.