OpenVPN Dockerissa ei voi avata /dev/net/tun: mitä puuttuu

Konttikuvat voivat sisältää kaikki tarvittavat OpenVPN-binääri- ja asetustiedostot ja epäonnistua silti ensimmäisessä verkkokutsussa. Virhe nimeää /dev/net/tun, koska sovellus pyysi ytimeltä TUN-rajapintaa eikä kontissa ollut laitesolmua eikä kykyä luoda sellaista. Nämä ovat kaksi erillistä lupaa, ja toisen korjaaminen jättää toisen täsmälleen sinne, missä se oli.

Niiden erottaminen vaatii yhden komennon kummallekin. Jälkimmäinen virheilmoitus kertoo, millä rajalla todella seisoi.

Laitesolmu ja kyky ovat kaksi ovea

Laitesolmu on tiedostojärjestelmän objekti, joten kontin on nähtävä se omassa mount-nimiavaruudessaan. Kyky on lupa, joten prosessi tarvitsee CAP_NET_ADMINin nimiavaruudessa, jossa rajapinta luodaan. Laitteen välittäminen ilman kykyä antaa solmun, joka avautuu, ja ioctlin, joka epäonnistuu. Kyvyn myöntäminen ilman laitetta jättää sovelluksen kykenemättömäksi avaamaan yhtään mitään, minkä vuoksi molemmat esiintyvät esimerkeissä yleensä yhdessä.

Dockerin devices-asetus kartoittaa isäntälaitteen konttiin, kun taas cap_add säätää kykyjoukkoa. Saman polun bind mount tuo tiedoston näkyviin soveltamatta laitekäytön semantiikkaa.

Toista se Compose-tiedoston ulkopuolella

Tarkista ennen palvelun muokkaamista, että isännällä on laite ja että paljas kontti voi luoda rajapinnan. Alla oleva komento on tarkoituksella minimaalinen, ja sen ainoa tarkoitus on erottaa isännän ongelma compose-ongelmasta. Jos se epäonnistuu, mikään compose-muutos ei auta.

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'

Puuttuva solmu isännällä tarkoittaa, että tun-moduuli ei ole käytettävissä, mikä on isännän puolen korjaus eikä kontin. Solmu, joka on olemassa mutta jota ei voi avata kontin sisällä, viittaa laitekäyttöön, ja viesti sanoo permission denied eikä no such file. Näiden kahden epäonnistumisen järjestys on koko diagnoosi. Kirjoita muistiin, kumman näit, ennen kuin muutat lippua.

TUNin jälkeiset virheet ovat eri ongelmia

Kun rajapinta ilmestyy, seuraavalla epäonnistumisella on eri omistaja. Todennusvirheet tarkoittavat, että tunneli saavutti palvelimen ja tunnistetiedot hylättiin, joten kyvyn muutokset eivät auta. Tunneli, joka muodostuu sovellusten yhä epäonnistuessa, viittaa reitteihin, edelleenlähetykseen, DNS-nimien selvitykseen kontin sisällä tai kontin omaan verkkorakenteeseen. Jokainen näistä on tavallinen verkkokysymys, johon TUN-lupa ei voi vastata. Alkuperäisen testin toistaminen jokaisen muutoksen jälkeen estää epäonnistumisia sulautumasta yhdeksi vaikutelmaksi.

Jokaisen asetuksen kopioiminen toimivasta esimerkistä on se tapa, jolla minimaalisesta korjauksesta tulee lukukelvoton palvelumääritelmä. Ota mukaan vain ne, joita tämä käyttöönotto tarvitsee, ja merkitse muistiin, miksi kukin on siellä.

Tarkista rajapinta kontin sisällä

Tarkista rajapinta ja kykyjoukko käynnissä olevan kontin sisältä eikä isännältä. Alla olevat komennot näyttävät laitesolmun, kyvyluettelon ja sen, voiko rajapinnan ylipäätään luoda. Suorita ne samassa kontissa, joka suorittaa asiakasta, ja asenna työkalut, jos kuva on minimaalinen.

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

Bounding setissä oleva mutta effective setistä puuttuva kyky käyttäytyy eri tavalla kuin kyky, jota ei koskaan myönnetty, ja capsh näyttää molemmat. Jos solmu on olemassa ja kyky on siellä mutta luonti epäonnistuu silti, ajonaikainen ympäristö pakottaa jotain muuta, kuten seccomp-profiilin tai AppArmor-käytännön, joka rajoittaa toimintoa. Se on kolmas raja, jonka dokumentoi ajonaikainen ympäristö eikä sovellus.

Kirjoita muistiin kontin liput, kuva ja jokaisen yrityksen tarkka virhe. Seuraava tämän muistiinpanon lukija voi kertoa, mikä ovi oli suljettu, toistamatta koko tutkimusta.