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

ફ્લેગ ખરેખર શું બદલે છે

વિશેષાધિકૃત કન્ટેનરને વિશાળ ક્ષમતાઓ અને હોસ્ટ ઉપકરણોની ઍક્સેસ મળે છે, જે નેટવર્ક પથને જરૂરી હોય તેના કરતાં ઘણી મોટી પરવાનગી છે. ચોક્કસ સમૂહને લોકવાયકા નહીં, રનટાઇમ દસ્તાવેજ કરે છે, અને Docker નું કન્ટેનર ચલાવવાનું દસ્તાવેજીકરણ ઉપલબ્ધ વિશેષાધિકાર વિકલ્પોનું વર્ણન કરે છે. એક વાર વાંચવું પૂરતું છે એ જોવા માટે કે ટનલિંગ આખા સમૂહનો નાનો ભાગ છે.

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

દરેક ભૂલને એક પૂર્વશરત સાથે મેળવો

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

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

લક્ષણ નહીં, જરૂરિયાત તપાસો

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

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

જે કન્ટેનર ઉપકરણ જોઈ શકે છે અને ક્ષમતા ધરાવે છે પણ તોપણ નિષ્ફળ જાય છે તે તમને કહે છે કે સમસ્યા બીજે ક્યાંક છે. તે ઉપયોગી પરિણામ છે, અને વિશેષાધિકૃત મોડ તેને છુપાવી દેતું.

હોસ્ટ પર ઉપકરણની પરવાનગીઓ પણ તપાસો, કારણ કે યોગ્ય રીતે આપેલો ઉપકરણ નોડ ખોટી જૂથ માલિકી સાથે ખૂટતી પરવાનગી જેવી જ ભૂલ ઉત્પન્ન કરે છે.

જે સાંકડી પરવાનગી કામ કરે તે નોંધો

જમાવટને જરૂરી હોય તે દરેક ઉપકરણ અને ક્ષમતા, તેને ન્યાયી ઠેરવનારી ભૂલ સાથે લખો. તે જ નોંધ આગલી વ્યક્તિને કંઈક સુરક્ષિત રીતે દૂર કરવા દે છે, અને કન્ટેનર વિશેષાધિકૃત હોવાનું જાણ થાય ત્યારે ઓડિટર તે જ માગશે.

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

સંબંધિત લેખો