કન્ટેનરમાં vpnc રૂટ-ફ્લશ ચેતવણી કેમ આવે છે

નવા કન્ટેનરના લોગ ઘણી વાર /proc/sys/net/ipv4/route/flush વિશે Read-only file system ફરિયાદ પર પૂરા થાય છે, અને એ લાઇનને એવી ટનલનો દોષ મળે છે જે સંપૂર્ણ સ્વસ્થ હોઈ શકે. તેની પાછળનું લખાણ કર્નલની એ એન્ટ્રીને લક્ષ્ય બનાવે છે જે IPv4 રૂટ કૅશ ગયા પછી હવે કંઈ ઉપયોગી કરતું નથી. કન્ટેનરની અંદર /proc/sys ફક્ત-વાંચન તરીકે માઉન્ટ થાય છે, તેથી કોઈ મૂલ્ય પહોંચે તે પહેલાં રીડાયરેક્શન નકારવામાં આવે છે અને શેલ એ નકાર છાપે છે. કાર્યરત ટનલ જૂની લાઇન સ્ક્રિપ્ટમાં રહે ત્યાં સુધી આ ચેતવણી છાપી શકે છે, અને --privileged લખાણને ક્યારેય અર્થપૂર્ણ બનાવતું નથી.

સ્ક્રિપ્ટ શું ફ્લશ કરવા માંગતી હતી

જૂની કનેક્શન સ્ક્રિપ્ટો કૅશ સફાઈ સાથે પૂરી થતી: કર્નલ નિયંત્રણ ફાઇલમાં મૂલ્ય લખવું અને IPv4 સ્ટેકને તેનો રાઉટિંગ કૅશ છોડી દેવા કહેવું, જેથી જૂની એન્ટ્રીઓની મુદત પૂરી થવાની રાહ જોયા વિના નવો ટનલ રૂટ પસંદ થાય. ફાઇલ /proc/sys/net/ipv4/ હેઠળ સરનામું કરેલી હતી, જેણે ક્રિયાને રાઉટિંગ આદેશને બદલે શેલ રીડાયરેક્શન બનાવી. કર્નલ 3.6 એ કૅશ દૂર કર્યો, અને તેની સાથે ફ્લશના અસ્તિત્વનું કારણ પણ. હાલના ડેટા માર્ગમાં કંઈ પણ એ લખાણ પર આધારિત નથી.

એન્ટ્રી પોતે જૂની ફક્ત-લખાણ ફાઇલ તરીકે ટકી રહી, તેથી જે સ્ક્રિપ્ટ હજી તેમાં લખે છે તે વાસ્તવિક માર્ગ અને વાસ્તવિક પરવાનગી-તપાસ સુધી પહોંચે છે. હોસ્ટ પર લખાણ સફળતા આપે છે અને કંઈ બદલતું નથી. કન્ટેનરમાં એ જ રીડાયરેક્શન ફક્ત-વાંચન /proc/sys ને અથડાય છે અને EROFS સાથે નિષ્ફળ જાય છે, જે શેલ ફક્ત-વાંચન ફાઇલસિસ્ટમ સંદેશ તરીકે છાપે છે. જે કર્નલમાં માર્ગ ખરેખર ગેરહાજર છે ત્યાં શબ્દરચના No such file or directory થઈ જાય છે, અને નિષ્કર્ષ બદલાતો નથી.

બે ભૂલો જુદી વાત કહે છે, અને તફાવત સ્પષ્ટ રાખવા યોગ્ય છે. Read-only file system એટલે કે કર્નલ એન્ટ્રી સુધી પહોંચ્યું અને લખાણ નકાર્યું; No such file or directory એટલે કે એન્ટ્રી ગઈ છે. કોઈ પણ સંદેશ ટનલ ઉપકરણ, રૂટ કે નામ-ઉકેલ વિશે જણાવતો નથી, તેથી કોઈ પણ વધુ વિશેષાધિકારને ન્યાયી ઠેરવી શકતો નથી.

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

વિશેષાધિકાર ઉમેરતા પહેલાં માઉન્ટ અને રૂટ તપાસો

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

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

grep નો જવાબ દેખાય તેનાથી નબળો છે, કારણ કે મેળ સાબિત કરે છે કે લાઇન હાજર છે, એ નહીં કે તે રક્ષા વિના ચાલે છે; જાળવાયેલી સ્ક્રિપ્ટ લખાણને એવા ગાર્ડની અંદર રાખી શકે છે જે તેને છોડી દે. findmnt -no OPTIONS /proc/sys માઉન્ટ સીધું નક્કી કરે છે, અને તે આઉટપુટમાં ro એટલે કે તે બિંદુ નીચેનું દરેક લખાણ નકારાય છે, સ્ક્રિપ્ટ ગમે તે કરે. પછી રૂટ લુકઅપ બતાવે છે કે એપ્લિકેશનને જરૂરી ગંતવ્ય ટનલ ઇન્ટરફેસ દ્વારા ઉકેલાય છે કે કન્ટેનરના ડિફોલ્ટ ગેટવે દ્વારા. ડિફોલ્ટ ગેટવે પસંદ કરતું લુકઅપ એટલે ટનલ ઊભી થઈ અને તેમાં કંઈ રૂટ થતું નથી, જે રાઉટિંગ સમસ્યા છે, વિશેષાધિકારની સમસ્યા નહીં.

સુધારો ખરેખર ક્યાંથી આવે છે

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

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