OpenVPN Dockeris ei suuda avada /dev/net/tun: mis on puudu

Konteineripildid võivad sisaldada kõiki vajalikke OpenVPN-i binaar- ja konfiguratsioonifaile ning siiski esimesel võrgukutsel läbi kukkuda. Viga nimetab /dev/net/tun, sest rakendus küsis tuumalt TUN-liidest ja konteineril ei olnud ei seadmesõlme ega võimalust seda luua. Need on kaks eraldi luba, ja ühe parandamine jätab teise täpselt sinna, kus see oli.

Nende eraldamiseks kulub kummagi jaoks üks käsk. Järgnev veateade ütleb, millisel piiril te tegelikult seisite.

Seadmesõlm ja võimekus on kaks ust

Seadmesõlm on failisüsteemi objekt, seega peab konteiner seda nägema oma mount-nimeruumis. Võimekus on luba, seega vajab protsess CAP_NET_ADMIN-i nimeruumis, kus liides luuakse. Seadme edasiandmine ilma võimekuseta annab teile sõlme, mis avaneb, ja ioctl-i, mis ebaõnnestub. Võimekuse andmine ilma seadmeta jätab rakenduse suutmatuks midagi avada, mistõttu esinevad mõlemad näidetes tavaliselt koos.

Dockeri devices-seade kaardistab hostseadme konteinerisse, samas kui cap_add kohandab võimekuste hulka. Sama tee bind mount toob faili vaatevälja ilma seadme juurdepääsu semantikat rakendamata.

Korrake seda väljaspool Compose-faili

Enne teenuse muutmist kontrollige, et hostil on seade ja et paljas konteiner suudab liidese luua. Allolev käsk on meelega minimaalne ja selle ainus eesmärk on eraldada hosti probleem compose'i probleemist. Kui see ebaõnnestub, ei aita ükski compose'i muudatus.

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'

Puuduv sõlm hostil tähendab, et tun-moodul pole saadaval, mis on hostipoole, mitte konteineri parandus. Sõlm, mis on olemas, kuid mida konteineri sees avada ei saa, viitab seadme juurdepääsule, ja teade ütleb permission denied, mitte no such file. Nende kahe tõrke järjekord on kogu diagnoos. Kirjutage üles, kumma te nägite, enne kui lippu muudate.

Vead pärast TUN-i on erinevad probleemid

Niipea kui liides ilmub, on järgmisel tõrkel teine omanik. Autentimisvead tähendavad, et tunnel jõudis serverini ja volitused lükati tagasi, seega võimekuse muudatused ei aita. Tunnel, mis luuakse, samal ajal kui rakendused ikka ebaõnnestuvad, viitab marsruutidele, edastamisele, DNS-i lahendamisele konteineri sees või konteineri enda võrgupaigutusele. Igaüks neist on tavaline võrguküsimus, millele TUN-i luba vastata ei saa. Algse testi kordamine pärast igat muudatust hoiab ära tõrgete sulandumise üheks muljeks.

Iga seade kopeerimine töötavast näitest on tee, kuidas minimaalsest parandusest saab loetamatu teenuse definitsioon. Võtke üle ainult need, mida see juurutus vajab, ja kirjutage üles, miks igaüks seal on.

Kontrollige liidest konteineri sees

Kontrollige liidest ja võimekuste hulka töötava konteineri seest, mitte hostilt. Allolevad käsud näitavad seadmesõlme, võimekuste loendit ja seda, kas liidest on üldse võimalik luua. Käivitage need samas konteineris, mis käitab klienti, ja paigaldage tööriistad, kui pilt on minimaalne.

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

Bounding set-is olemas olev, kuid effective set-is puuduv võimekus käitub teisiti kui see, mida kunagi ei antud, ja capsh näitab mõlemat. Kui sõlm on olemas ja võimekus on olemas, aga loomine ikka ebaõnnestub, rakendab käituskeskkond midagi muud, näiteks seccomp-profiili või AppArmor-poliitikat, mis seda toimingut piirab. See on kolmas piir, mida dokumenteerib käituskeskkond, mitte rakendus.

Kirjutage üles konteineri lipud, pilt ja iga katse täpne viga. Järgmine inimene, kes seda märkust loeb, oskab öelda, milline uks oli suletud, ilma kogu uurimist kordamata.