ip netns exec અને DNS: નેમસ્પેસની અંદર નામો કેમ નિષ્ફળ જાય છે

એક કમાન્ડ VPN નેમસ્પેસની અંદર 10.8.0.5 સુધી કોઈ ફરિયાદ વિના પહોંચે છે, અને એ જ કમાન્ડ હોસ્ટનામ વાપરે તે ક્ષણે નિષ્ફળ જાય છે. નેમસ્પેસ પાસે તેના પોતાના ઇન્ટરફેસ, રૂટ અને સોકેટ છે; તેની પોતાની રિઝોલ્વર ફાઇલ નથી. જો કોઈ ત્યાં એક મૂકે નહીં, તો અંદરની પ્રક્રિયા હોસ્ટની /etc/resolv.conf વાંચે છે અને એ નેટવર્ક સ્ટેક પરથી પહોંચી ન શકાય તેવા સર્વરને પૂછે છે.

આ રૂટિંગ સમસ્યા નહીં, ફાઇલ-પસંદગીની સમસ્યા છે, અને એટલે જ સંખ્યાત્મક ગંતવ્ય હજુ પણ કામ કરે છે.

પ્રક્રિયાને ખરેખર મળતું રિઝોલ્વર દૃશ્ય તપાસો

તમે વાપરેલું શેલ તમે ડિબગ કરી રહ્યા છો તે પ્રક્રિયા જેટલું જ છે એમ ન માનો. ગ્રાફિકલ એપ્લિકેશન, systemd યુનિટ અને કન્ટેનર દરેક અલગ માઉન્ટ કે નેટવર્ક સંદર્ભમાં પ્રવેશી શકે છે. એ જ લોન્ચ માર્ગ દ્વારા લુકઅપ ચલાવો, અને અંદરથી રિઝોલ્વર ફાઇલ છાપો.

ip netns add થી બનેલા નેમસ્પેસ માટે માત્ર-વાંચન તપાસ ટૂંકી છે:

ip netns exec vpn cat /etc/resolv.conf

પરિણામ પહોંચી શકાય તેવું સરનામું, loopback સ્ટબ, કે અલગ પહોંચ ધરાવતા સ્થળે ઇશારો કરતી સિમ્બોલિક કડી કહે છે કે નહીં તે નોંધો.

exec સહાયક ખરેખર શું માઉન્ટ કરે છે

ip-netns સાધન દરેક નેમસ્પેસનું રૂપરેખાંકન /etc/netns/NAME/ હેઠળ દસ્તાવેજ કરે છે. જ્યારે તે પ્રક્રિયા લોન્ચ કરે છે, ત્યારે સહાયક માઉન્ટ નેમસ્પેસ બનાવે છે અને એ ફાઇલોને તેમના સામાન્ય માર્ગો પર bind-mount કરે છે, જેથી પ્રક્રિયા નેમસ્પેસ-વિશિષ્ટ નકલ જુએ છે. આ આ ચોક્કસ લોન્ચરની સુવિધા છે. બીજા માર્ગે, જેમ કે unshare કે કન્ટેનર રનટાઇમ દ્વારા નેટવર્ક નેમસ્પેસમાં પ્રવેશવું, તેને આપોઆપ પુનઃઉત્પાદિત કરતું નથી.

અહીં ફાંસો loopback રિઝોલ્વર છે: 127.0.0.53 એટલે નેમસ્પેસનું પોતાનું loopback, હોસ્ટનું સ્ટબ નહીં. જે સ્ટબ ફક્ત હોસ્ટ નેમસ્પેસમાં સાંભળે છે તે નવા નેમસ્પેસમાં સેવા બનતું નથી.

નેમસ્પેસ પહોંચી શકે એવું રિઝોલ્વર પસંદ કરો

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

પોતાનું રિઝોલ્વર ધરાવતી એપ્લિકેશનો, જેમ કે DNS over HTTPS વાપરતી એક, ફાઇલને સંપૂર્ણ અવગણી શકે છે. જો સાધનનું પોતાનું DNS સેટિંગ હોય, તો resolv.conf બદલવાથી તેના પર અસર નહીં થાય, અને નેમસ્પેસ કદી સમસ્યા જ નહોતું.

ફાઇલ યોગ્ય જગ્યાએ લખો

/etc/netns/NAME/resolv.conf હેઠળ નેમસ્પેસ-વિશિષ્ટ ફાઇલ બનાવો અને લોન્ચરને તે રજૂ કરવા દો. તેને ન્યૂનતમ રાખો: એક કે બે પહોંચી શકાય તેવા સર્વર અને કાર્યને જરૂરી શોધ ડોમેન. એક જૂથની પ્રક્રિયાઓ માટે બનાવેલું દૃશ્ય સુધારવા હોસ્ટની જનરેટ થયેલી રિઝોલ્વર ફાઇલ સંપાદિત કરશો નહીં, કારણ કે તે મશીનની દરેક એપ્લિકેશન બદલી નાખે છે. જો હોસ્ટ રિઝોલ્વર મેનેજર વાપરે છે, તો તેની સામે લડવાને બદલે એ મેનેજર દ્વારા નેમસ્પેસનો માર્ગ ગોઠવો.

રનબુકમાં ફાઇલનો સમાવેશ નોંધો. નહીં તો પછીની વ્યક્તિ હોસ્ટનું રિઝોલ્વર ચકાસશે, કામ કરતો જવાબ જોશે અને તારણ કાઢશે કે નેમસ્પેસ ઠીક છે.

આખો માર્ગ ફરી ચકાસો

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

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