Docker માં OpenVPN /dev/net/tun ખોલી શકતું નથી: શું ખૂટે છે

કન્ટેનર ઈમેજ તેમને જરૂરી હોય તેવી દરેક OpenVPN બાઈનરી અને કન્ફિગરેશન ફાઈલ ધરાવી શકે છે અને છતાં પ્રથમ નેટવર્ક કૉલ પર નિષ્ફળ જાય છે. ભૂલ /dev/net/tun નું નામ આપે છે કારણ કે એપ્લિકેશને કર્નલને TUN ઇન્ટરફેસ માટે પૂછ્યું હતું અને કન્ટેનર પાસે ન તો ઉપકરણ નોડ હતો ન તો તેને બનાવવાની ક્ષમતા. આ બે અલગ પરવાનગીઓ છે, અને એક સુધારવાથી બીજી બરાબર જ્યાં હતી ત્યાં જ રહે છે.

તેમને અલગ કરવા માટે દરેક માટે એક આદેશ જોઈએ. તે પછીનો ભૂલ સંદેશ તમને કહે છે કે તમે ખરેખર કઈ સીમા પર ઊભા હતા.

ઉપકરણ નોડ અને ક્ષમતા બે દરવાજા છે

ઉપકરણ નોડ ફાઈલસિસ્ટમ ઑબ્જેક્ટ છે, તેથી કન્ટેનરને તેને તેના પોતાના માઉન્ટ નેમસ્પેસમાં જોવું પડે. ક્ષમતા એ પરવાનગી છે, તેથી પ્રક્રિયાને જે નેમસ્પેસમાં ઇન્ટરફેસ બનશે ત્યાં CAP_NET_ADMIN ની જરૂર છે. ક્ષમતા વગર ઉપકરણ પસાર કરવાથી તમને ખૂલતો નોડ અને નિષ્ફળ જતો ioctl મળે છે. ઉપકરણ વગર ક્ષમતા આપવાથી એપ્લિકેશન કંઈપણ ખોલી શકતી નથી, તેથી જ ઉદાહરણોમાં બંને સામાન્ય રીતે સાથે દેખાય છે.

Docker નું devices સેટિંગ હોસ્ટ ઉપકરણને કન્ટેનરમાં મેપ કરે છે, જ્યારે cap_add ક્ષમતા સેટને સમાયોજિત કરે છે. એ જ પાથનું bind mount ઉપકરણ પ્રવેશની અર્થશાસ્ત્ર લાગુ કર્યા વગર ફાઈલને દૃષ્ટિમાં મૂકે છે.

તેને Compose ફાઈલની બહાર પુનઃઉત્પન્ન કરો

સેવા સંપાદિત કરતા પહેલાં ચકાસો કે હોસ્ટ પાસે ઉપકરણ છે અને નગ્ન કન્ટેનર ઇન્ટરફેસ બનાવી શકે છે. નીચેનો આદેશ જાણી જોઈને ન્યૂનતમ છે, અને તેનો એકમાત્ર હેતુ હોસ્ટ સમસ્યાને compose સમસ્યાથી અલગ કરવાનો છે. જો તે નિષ્ફળ જાય, તો કોઈ પણ compose ફેરફાર મદદ કરશે નહીં.

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'

હોસ્ટ પર નોડ ખૂટે તેનો અર્થ tun મોડ્યુલ ઉપલબ્ધ નથી, જે કન્ટેનરની નહીં પણ હોસ્ટ બાજુની સમસ્યાનું સુધારણું છે. નોડ હોવા છતાં કન્ટેનરની અંદર ખોલી ન શકાય તે ઉપકરણ પ્રવેશ તરફ ઈશારો કરે છે, અને સંદેશ no such file ને બદલે permission denied કહેશે. આ બે નિષ્ફળતાઓનો ક્રમ જ આખું નિદાન છે. કોઈ ફ્લેગ બદલતા પહેલાં તમે કઈ જોઈ તે લખી રાખો.

TUN પછીની ભૂલો અલગ સમસ્યાઓ છે

ઇન્ટરફેસ દેખાતાં જ આગલી નિષ્ફળતાનો બીજો માલિક હોય છે. પ્રમાણીકરણ ભૂલોનો અર્થ ટનલ સર્વર સુધી પહોંચી અને ઓળખપત્રો નકારાયા, તેથી ક્ષમતા ફેરફાર મદદ કરશે નહીં. ટનલ સ્થપાયા પછી પણ એપ્લિકેશનો નિષ્ફળ જાય તો તે રૂટ, ફોરવર્ડિંગ, કન્ટેનરની અંદર DNS રિઝોલ્યુશન કે કન્ટેનરની પોતાની નેટવર્ક ગોઠવણ તરફ ઈશારો કરે છે. તેમાંનું દરેક સામાન્ય નેટવર્કિંગ પ્રશ્ન છે જેનો TUN પરવાનગી જવાબ આપી શકતી નથી. દરેક ફેરફાર પછી મૂળ પરીક્ષણનું પુનરાવર્તન નિષ્ફળતાઓને એક છાપમાં ભળી જતી અટકાવે છે.

કાર્યકારી ઉદાહરણમાંથી દરેક સેટિંગ કૉપી કરવી એ જ રીત છે જેમાં ન્યૂનતમ સુધારો અવાંચ્ય સેવા વ્યાખ્યા બની જાય છે. આ ડિપ્લોયમેન્ટને જે જોઈએ તે જ લાવો અને દરેક કેમ છે તે લખી રાખો.

કન્ટેનરની અંદર ઇન્ટરફેસ ચકાસો

ઇન્ટરફેસ અને ક્ષમતા સેટ ચકાસો હોસ્ટ પરથી નહીં પણ ચાલતા કન્ટેનરની અંદરથી. નીચેના આદેશો ઉપકરણ નોડ, ક્ષમતાની સૂચિ અને ઇન્ટરફેસ બની શકે છે કે નહીં તે દર્શાવે છે. ક્લાયન્ટ ચલાવતા એ જ કન્ટેનરમાં તે ચલાવો, અને ઈમેજ ન્યૂનતમ હોય તો ટૂલિંગ ઇન્સ્ટોલ કરો.

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

bounding set માં હાજર પણ effective set માં ગેરહાજર ક્ષમતા ક્યારેય ન આપેલી ક્ષમતાથી અલગ વર્તે છે, અને capsh બંને દર્શાવે છે. નોડ હોય અને ક્ષમતા હોય છતાં બનાવવું નિષ્ફળ જાય તો રનટાઇમ બીજું કંઈક લાગુ કરે છે, જેમ કે seccomp પ્રોફાઇલ કે AppArmor નીતિ જે ક્રિયાને મર્યાદિત કરે છે. તે ત્રીજી સીમા છે, જે એપ્લિકેશન દ્વારા નહીં પણ રનટાઇમ દ્વારા દસ્તાવેજીકૃત છે.

કન્ટેનર ફ્લેગ, ઈમેજ અને દરેક પ્રયાસની ચોક્કસ ભૂલ લખી રાખો. તે નોંધ વાંચનારી આગલી વ્યક્તિ આખી તપાસનું પુનરાવર્તન કર્યા વગર કહી શકશે કે કયો દરવાજો બંધ હતો.