OpenVPN in Docker kan /dev/net/tun niet openen: wat ontbreekt
Een TUN-node en de netwerkmogelijkheid zijn twee afzonderlijke rechten. Open beide en lees daarna de volgende fout op zijn eigen voorwaarden in plaats van dezelfde oplossing te herhalen.
Containerimages kunnen elk benodigd OpenVPN-binary en configuratiebestand bevatten en toch bij de eerste netwerkaanroep mislukken. De fout noemt /dev/net/tun omdat de toepassing de kernel om een TUN-interface vroeg en de container noch het apparaatknooppunt noch de mogelijkheid had er een te maken. Dat zijn twee afzonderlijke rechten, en het ene repareren laat het andere precies waar het was.
Ze scheiden kost voor elk één opdracht. Het foutbericht daarna vertelt u bij welke grens u werkelijk stond.
Het apparaatknooppunt en de mogelijkheid zijn twee deuren
Het apparaatknooppunt is een bestandssysteemobject, dus een container moet het in zijn eigen mount-namespace zien. De mogelijkheid is een recht, dus het proces heeft CAP_NET_ADMIN nodig in de namespace waar de interface wordt gemaakt. Het apparaat doorgeven zonder de mogelijkheid levert een knooppunt op dat opent en een ioctl die mislukt. De mogelijkheid geven zonder het apparaat laat de toepassing helemaal niets kunnen openen, daarom verschijnen de twee in voorbeelden meestal samen.
De devices-instelling van Docker koppelt het hostapparaat in de container, terwijl cap_add de mogelijkhedenset aanpast. Een bind mount van hetzelfde pad zet het bestand in beeld zonder de semantiek van apparaattoegang toe te passen.
Reproduceer het buiten het Compose-bestand
Controleer vóór het bewerken van de service dat de host het apparaat heeft en dat een kale container een interface kan maken. De opdracht hieronder is bewust minimaal, en het enige doel is een hostprobleem van een compose-probleem te scheiden. Als hij mislukt, helpt geen enkele compose-wijziging.
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'
Een ontbrekend knooppunt op de host betekent dat de tun-module niet beschikbaar is, wat een oplossing aan de hostkant is en niet in de container. Een knooppunt dat bestaat maar niet in de container kan worden geopend, wijst op apparaattoegang, en het bericht zal permission denied zeggen in plaats van no such file. De volgorde van die twee fouten is de hele diagnose. Schrijf op welke u zag voordat u een vlag wijzigt.
De fouten na TUN zijn andere problemen
Zodra de interface verschijnt, heeft de volgende fout een andere eigenaar. Authenticatiefouten betekenen dat de tunnel de server bereikte en de inloggegevens werden geweigerd, dus wijzigingen aan de mogelijkheden helpen niet. Een tunnel die tot stand komt terwijl toepassingen nog steeds falen, wijst op routes, doorsturen, DNS-resolutie in de container of de eigen netwerkindeling van de container. Elk daarvan is een gewone netwerkvraag die het TUN-recht niet kan beantwoorden. De oorspronkelijke test na elke wijziging herhalen voorkomt dat de fouten tot één indruk samensmelten.
Elke instelling uit een werkend voorbeeld kopiëren is hoe een minimale oplossing een onleesbare servicedefinitie wordt. Neem alleen die over die deze uitrol nodig heeft en noteer waarom elk er is.
Controleer de interface in de container
Controleer de interface en de mogelijkhedenset van binnenuit de draaiende container in plaats van vanaf de host. De opdrachten hieronder tonen het apparaatknooppunt, de mogelijkhedenlijst en of er überhaupt een interface kan worden gemaakt. Voer ze uit in dezelfde container die de client draait, en installeer de hulpprogramma's als de image minimaal is.
ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9
Een mogelijkheid die in de bounding set zit maar in de effective set ontbreekt, gedraagt zich anders dan een die nooit is gegeven, en capsh toont beide. Als het knooppunt bestaat en de mogelijkheid er is terwijl het maken nog steeds mislukt, dwingt de runtime iets anders af, zoals een seccomp-profiel of een AppArmor-beleid dat de bewerking beperkt. Dat is een derde grens, gedocumenteerd door de runtime en niet door de toepassing.
Noteer de containervlaggen, de image en de exacte fout van elke poging. De volgende persoon die die notitie leest, kan zien welke deur dicht was zonder het hele onderzoek te herhalen.