resolv.conf તમારું VPN DNS કેમ દેખાડે છે પણ લુકઅપ તેને અવગણે છે

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

resolv.conf નામના ત્રણ ઑબ્જેક્ટ

resolved ધરાવતા હોસ્ટ પર /etc/resolv.conf સામાન્ય રીતે /run/systemd/resolve/stub-resolv.conf તરફની સિમ્બોલિક લિંક હોય છે. તે લક્ષ્યમાં સ્થાનિક stub શ્રોતાનું સરનામું, 127.0.0.53, તથા resolved એ ગણેલા શોધ ડોમેન રહે છે. તે સ્થિતિનું દૃશ્ય છે, સ્થિતિ પોતે નહીં.

સ્થિતિ resolved ના દરેક લિંક માટેના રૂપરેખાંકનમાં રહે છે, તેથી resolvectl status ફાઇલ સાથે અસહમત થઈને પણ સાચું હોઈ શકે. દરેક લિંક પોતાના સર્વર અને પોતાના રૂટિંગ ડોમેન ધરાવે છે, અને ક્વેરી આવે ત્યારે stub તે ડેટાની સલાહ લે છે. systemd-resolved મેન્યુઅલ જનરેટ થયેલી ફાઇલો અને દરેક લિંકનું મોડેલ વર્ણવે છે; દૃશ્ય અને સ્થિતિ વચ્ચેનું વિભાજન યાદ રાખવા જેવો ભાગ છે. સિમ્બોલિક લિંકનું લક્ષ્ય બદલવાથી પરંપરાગત ક્લાયન્ટ જે વાંચે છે તે બદલાય છે, રિઝોલ્વર જે જાણે છે તે નહીં.

ત્રીજું ઑબ્જેક્ટ, /run/systemd/resolve/resolv.conf, દરેક લિંકને એક જ સર્વર યાદીમાં સપાટ કરે છે. તે ફાઇલ તરફ નિર્દેશિત પ્રોગ્રામ ક્વેરી સીધી યાદીમાંના સર્વર પર મોકલે છે અને stub છોડી દે છે, તેથી દરેક લિંકની નીતિ હવે તેને લાગુ પડતી નથી. આથી એક જ મશીન પરના બે પ્રોગ્રામ એક જ નામનો જુદો જવાબ આપી શકે છે, અને બંમાંથી કોઈ તૂટેલું નથી.

NSS દ્વારા એક લુકઅપ અનુસરો

glibc નામનો જવાબ કોણ આપશે તે નક્કી કરવા /etc/nsswitch.conf વાંચે છે. જે hosts લાઇનમાં resolve છે તે પ્રશ્ન nss-resolve પર મોકલે છે, જે D-Bus દ્વારા resolved ને પૂછે છે અને દરેક લિંકનો જવાબ મેળવે છે. ફક્ત files dns ધરાવતી લાઇન ક્વેરી /etc/resolv.conf જે સરનામું ધરાવે છે તેના પર મોકલે છે.

આ એક લાઇન બ્રાઉઝર અને dig વચ્ચેના મોટા ભાગના મતભેદ સમજાવે છે. dig સીધું resolv.conf વાંચે છે અને NSS ને ક્યારેય અડતું નથી, તેથી તે એપ્લિકેશન વાપરે છે તે માર્ગને બદલે stub કે ઉપરના સર્વરની કસોટી કરે છે. getent hosts internal.example NSS માંથી પસાર થાય છે, અને તેના જવાબને dig ના જવાબ સાથે સરખાવવો એ પહેલું ઉપયોગી માપન છે.

પોતાનું રિઝોલ્વર સાથે લાવતી, કે નિશ્ચિત એન્ડપોઇન્ટ સાથે HTTPS પર DNS બોલતી એપ્લિકેશનો બંને માર્ગ ટાળે છે. resolv.conf માં કે resolved ની સ્થિતિમાં કંઈ તેમને મર્યાદિત કરતું નથી.

ફાઇલ કોની માલિકીની છે અને ક્યાં નિર્દેશ કરે છે તે તપાસો

કંઈ બદલતા પહેલાં લિંક સાંકળ વાંચો, કારણ કે માલિકી નક્કી કરે છે કઈ ફાઇલ પ્રમાણભૂત છે. નીચેનો દરેક આદેશ ફક્ત સ્થિતિ વાંચે છે.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

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

જો સાંકળ બીજા પેકેજે સંભાળેલી ફાઇલ પર પૂરી થાય, તો VPN ક્લાયન્ટ અને તે પેકેજ એ સમેલ કરવાના બે માલિક છે. લિંક બદલવાથી એક માલિકનું કામ ફેંકાય છે અને બીજાનું તેની જગ્યાએ રહે છે.

લિંકના માલિક પાસે સુધારો કરો

VPN કનેક્શને પોતાના સર્વર અને ડોમેન પોતાની લિંક પર નોંધવા જોઈએ, પછી ડિસ્કનેક્ટ થાય ત્યારે તેમને પાછા ખેંચી લેવા જોઈએ. NetworkManager નું resolved એકીકરણ અને ક્લાયન્ટનું પોતાનું સહાયક બંને એ રીતે કામ કરે છે; ફક્ત resolv.conf ફરી લખતી સ્ક્રિપ્ટ એમ કરતી નથી.

પહેલેથી હાજર લિંક પર, રનટાઇમ સેટિંગ્સ પદ્ધતિ દેખાડે છે. resolvectl dns tun0 10.40.0.53 એક સર્વર જોડે છે, અને resolvectl domain tun0 '~corp.example' એક રૂટિંગ ડોમેન જોડે છે. ટિલ્ડા (~) એ ભાર વહેતું અક્ષર છે: તે તે પ્રત્યયની ક્વેરીને આ લિંક સુધી મર્યાદિત કરે છે અને બાકીનું બધું શાંત રહેવા દે છે, જ્યારે તેના વગરનું એ જ મૂલ્ય શોધ ડોમેન બની જાય છે અને વિભાજન વરાળ બની જાય છે. તે સરનામાં લેબ ઉદાહરણો છે, કાયમી રૂપરેખાંકન નહીં. resolvectl query host.corp.example સાથે ખાતરી કરો અને વાંચો કઈ લિંકે જવાબ આપ્યો.

નોંધાયેલા સર્વરને હજી પણ માર્ગની જરૂર છે. ક્વેરી યોગ્ય લિંક સુધી પહોંચીને સમય પૂરો થાય ત્યારે દોષ રિઝોલ્વરની માલિકીમાં નહીં, ટનલ દ્વારા પહોંચવાની ક્ષમતામાં છે.

કાર્યરત સ્થિતિ કેવી દેખાય છે

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

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