OpenVPN í Docker getur ekki opnað /dev/net/tun: hvað vantar

Geymsluskrár gáma geta borið allar OpenVPN tvíundar- og stillingarskrár sem þær þurfa og samt mistekist við fyrsta netkallið. Villan nefnir /dev/net/tun vegna þess að forritið bað kjarnann um TUN-tengi og gáminn hafði hvorki tækishnútinn né færni til að búa hann til. Þetta eru tvö aðskilin leyfi, og að laga annað skilur hitt eftir nákvæmlega þar sem það var.

Að aðskilja þau krefst einnar skipunar fyrir hvort. Villuboðin á eftir segja þér við hvaða mörk þú stóðst í raun.

Tækishnúturinn og færni eru tvær dyr

Tækishnúturinn er hlutur í skráarkerfinu, svo gámur þarf að sjá hann í eigin uppsetningarnafnrými. Færni er leyfi, svo ferlið þarf CAP_NET_ADMIN í nafnrýminu þar sem tengið verður búið til. Að gefa tækið áfram án færninnar gefur þér hnút sem opnast og ioctl sem mistekst. Að veita færnina án tækisins skilur forritið eftir ófært um að opna hvað sem er, og þess vegna birtast þau tvö venjulega saman í dæmum.

devices-stilling Docker varpar tæki hýsilsins inn í gáminn, en cap_add stillir færnimengið. Bind mount á sömu slóð setur skrána í sýn án þess að beita merkingu tækisaðgangs.

Endurskapið það utan Compose-skrárinnar

Áður en þú breytir þjónustunni skaltu staðfesta að hýsillinn hafi tækið og að ber gámur geti búið til tengi. Skipunin hér fyrir neðan er viljandi lágmarks, og eina tilgangur hennar er að aðskilja vandamál hýsilsins frá compose-vandamáli. Ef hún mistekst mun engin compose-breyting hjálpa.

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'

Vantar hnút á hýsilnum þýðir að tun-einingin er ekki tiltæk, sem er lagfæring á hýsilhlið en ekki í gámnum. Hnútur sem er til en ekki er hægt að opna inni í gámnum bendir á tækisaðgang, og skilaboðin munu segja permission denied í stað no such file. Röð þessara tveggja mistaka er öll greiningin. Skrifaðu niður hvort þú sást áður en þú breytir fána.

Villurnar eftir TUN eru önnur vandamál

Um leið og tengið birtist hefur næsta mistök annan eiganda. Auðkenningarvillur þýða að göngin náðu þjóninum og skírteini voru hafnað, svo breytingar á færni munu ekki hjálpa. Göng sem myndast á meðan forrit mistakast enn benda á slóðir, áframsendingu, DNS-upplausn inni í gámnum eða eigið netfyrirkomulag gámsins. Hvert þessara er venjuleg netspurning sem TUN-leyfið getur ekki svarað. Að endurtaka upprunalegu prófið eftir hverja breytingu kemur í veg fyrir að mistökin renni saman í eina tilfinningu.

Að afrita hverja stillingu úr vinnandi dæmi er leiðin sem lágmarkslagfæring verður ólæsileg þjónustuskilgreining. Taktu aðeins þær sem þessi uppsetning þarf og skrifaðu hvers vegna hver er þar.

Staðfestu tengið inni í gámnum

Athugaðu tengið og færnimengið innan frá gámnum sem er í gangi í stað hýsilsins. Skipanirnar hér fyrir neðan sýna tækishnútinn, færnalistann og hvort hægt sé að búa til tengi yfirleitt. Keyrðu þær í sama gámnum og keyrir biðlarann, og settu upp verkfærin ef myndin er lágmarks.

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

Færni sem er til í bounding set en vantar í effective set hegðar sér öðruvísi en sú sem aldrei var veitt, og capsh sýnir bæði. Ef hnúturinn er til og færni er þar á meðan sköpun mistekst enn, þá er runtime að þvinga eitthvað annað, svo sem seccomp-snið eða AppArmor-stefnu sem takmarkar aðgerðina. Það er þriðja landamærið, skjalfest af runtime en ekki af forritinu.

Skrifaðu niður fána gámsins, myndina og nákvæmu villuna úr hverri tilraun. Næsta manneskja sem les þá athugasemd getur sagt hvaða dyr voru lokaðar án þess að endurtaka alla rannsóknina.