OpenVPN în Docker nu poate deschide /dev/net/tun: ce lipsește
Un nod TUN și capacitatea de rețea sunt două permisiuni separate. Deschideți ambele și apoi citiți următoarea eroare în condițiile ei proprii, în loc să repetați aceeași remediere.
Imaginile de container pot conține toate fișierele binare și de configurare OpenVPN de care au nevoie și totuși pot eșua la primul apel de rețea. Eroarea numește /dev/net/tun pentru că aplicația a cerut nucleului o interfață TUN, iar containerul nu avea nici nodul de dispozitiv, nici capacitatea de a crea unul. Sunt două permisiuni separate, iar repararea uneia o lasă pe cealaltă exact unde era.
Separarea lor costă o comandă pentru fiecare. Mesajul de eroare de după vă spune la ce graniță stăteați de fapt.
Nodul de dispozitiv și capacitatea sunt două uși
Nodul de dispozitiv este un obiect al sistemului de fișiere, așa că un container trebuie să îl vadă în propriul spațiu de nume de montare. Capacitatea este o permisiune, așa că procesul are nevoie de CAP_NET_ADMIN în spațiul de nume în care va fi creată interfața. Trecerea dispozitivului fără capacitate vă oferă un nod care se deschide și un ioctl care eșuează. Acordarea capacității fără dispozitiv lasă aplicația incapabilă să deschidă orice, motiv pentru care cele două apar de obicei împreună în exemple.
Setarea devices a Docker mappează dispozitivul gazdă în container, în timp ce cap_add ajustează setul de capacități. Un bind mount al aceleiași căi pune fișierul în câmpul vizual fără a aplica semantica accesului la dispozitiv.
Reproduceți acest lucru în afara fișierului Compose
Înainte de a edita serviciul, verificați că gazda are dispozitivul și că un container gol poate crea o interfață. Comanda de mai jos este deliberat minimală, iar singurul ei scop este să separe o problemă a gazdei de o problemă de compose. Dacă eșuează, nicio modificare de compose nu va ajuta.
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'
Un nod lipsă pe gazdă înseamnă că modulul tun nu este disponibil, ceea ce este o remediere de partea gazdei și nu a containerului. Un nod care există dar nu poate fi deschis în container indică accesul la dispozitiv, iar mesajul va spune permission denied în loc de no such file. Ordinea acestor două eșecuri este întregul diagnostic. Notați pe care l-ați văzut înainte de a schimba vreun indicator.
Erorile de după TUN sunt probleme diferite
De îndată ce interfața apare, următorul eșec are alt proprietar. Erorile de autentificare înseamnă că tunelul a ajuns la server și acreditările au fost respinse, așa că modificările de capacitate nu vor ajuta. Un tunel care se stabilește în timp ce aplicațiile încă eșuează indică rute, redirecționare, rezolvare DNS în container sau propria configurație de rețea a containerului. Fiecare dintre acestea este o întrebare obișnuită de rețea la care permisiunea TUN nu poate răspunde. Repetarea testului original după fiecare modificare împiedică eșecurile să se contopească într-o singură impresie.
Copierea fiecărei setări dintr-un exemplu funcțional este modul în care o remediere minimă devine o definiție de serviciu ilizibilă. Aduceți doar pe cele de care are nevoie acest deployment și notați de ce este fiecare acolo.
Verificați interfața din interiorul containerului
Verificați interfața și setul de capacități din interiorul containerului care rulează, nu de pe gazdă. Comenzile de mai jos arată nodul de dispozitiv, lista de capacități și dacă o interfață poate fi creată deloc. Rulați-le în același container care rulează clientul și instalați instrumentele dacă imaginea este minimală.
ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9
O capacitate prezentă în bounding set dar absentă din effective set se comportă diferit de una care nu a fost niciodată acordată, iar capsh le arată pe amândouă. Dacă nodul există și capacitatea este acolo în timp ce crearea încă eșuează, mediul de execuție impune altceva, cum ar fi un profil seccomp sau o politică AppArmor care restricționează operația. Aceasta este o a treia graniță, documentată de mediul de execuție și nu de aplicație.
Notați indicatorii containerului, imaginea și eroarea exactă din fiecare încercare. Următoarea persoană care citește acea notă va putea spune care ușă era închisă fără a repeta întreaga investigație.