/etc/resolv.conf માટે સ્પર્ધા કરતી બે Linux સેવાઓને રોકો

DNS વારંવાર પાછું જૂની સ્થિતિમાં આવે છે, VPN ફરીથી જોડાવું તમારું સુધારણ રદ કરે છે, અને આખરે ટીમમાં કોઈ ફાઇલને લૉક કરવાનું સૂચન કરે છે. એ ક્રમ લક્ષણ છે, ઉકેલ નહીં: બે ઘટકો બંને માને છે કે /etc/resolv.conf તેમનું છે, અને જે છેલ્લે લખે તે જીતે છે. ફાઇલ લૉક કરવાથી માલિકીનો સંઘર્ષ ઉકેલાતો નથી, તે ફક્ત તેને છુપાવે છે અને સાથે તમે ખરેખર ઇચ્છતા હતા તે ઘટકને તોડે છે. નીચેની ચાર તપાસો ક્રમમાં કરો અને ગોઠવણને તે સ્તરે સુધારો જે તેનો માલિક છે, ફાઇલ પર નહીં.

તપાસ 1: તે સિમ્બોલિક લિંક છે કે નહીં, અને ક્યાં

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

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

તપાસ 2: કયો ડીમન ચાલી રહ્યો છે

શું સ્થાપિત છે તે નહીં, શું ખરેખર સક્રિય છે તે શોધો. આધુનિક વિતરણમાં ઘણા રિઝોલ્વર હોઈ શકે છે, અને લૂપબેક ઇન્ટરફેસ પર પોર્ટ 53 ધરાવતું એ જ જવાબ આપે છે:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

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

NetworkManager નું પોતાનું કન્ફિગરેશન નક્કી કરે છે કે તે આમાંથી કયું બેકએન્ડ વાપરે છે. મુખ્ય કન્ફિગરેશન ફાઇલમાંની તેની dns= સેટિંગ તેના આંતરિક રિઝોલ્વર, dnsmasq, systemd-resolved અને none વચ્ચે પસંદગી કરે છે, અને વિતરણે તમારા વતી પસંદ કર્યું હોઈ શકે. આ હોસ્ટ પર “DNS ઠીક કરવું” નો અર્થ શું છે તે નક્કી કરતા પહેલાં એ સેટિંગ વાંચો.

તપાસ 3: VPN ક્લાયન્ટને શું લખવાની પરવાનગી છે

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

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

અનુમાન કરવાને બદલે ક્લાયન્ટના up અને down હૂક વાંચો. /etc/openvpn/up.sh અથવા સમાન ડિરેક્ટરીમાં થોડી shell લાઇનો એ વર્તન સમજાવે છે જે નહીં તો અવ્યવસ્થિત લાગે છે, અને તે જ જગ્યા છે જ્યાં તમે ક્લાયન્ટને સ્પર્ધા કરવાને બદલે સહકાર આપવા મજબૂર કરી શકો છો.

તપાસ 4: તેને માલિક પાસે સુધારો, ફાઇલમાં નહીં

માલિક ખબર પડ્યા પછી, એ માલિકના સમર્થિત ઇન્ટરફેસ દ્વારા DNS ગોઠવો. systemd-resolved માટે તેનો અર્થ સ્થિર ફાઇલને બદલે દરેક લિંકની સેટિંગ્સ અને રૂટિંગ ડોમેન્સ; NetworkManager માટે કનેક્શન પ્રોફાઇલની DNS સેટિંગ્સ અને પસંદ કરેલું બેકએન્ડ; resolvconf એકીકરણ વાપરતા વિતરણ માટે એ સહાયક દ્વારા લખવું.

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

જ્યાં બે ઘટકોએ ખરેખર સહઅસ્તિત્વમાં રહેવું જ પડે, ત્યાં તેમને અલગ કામો આપો. નેટવર્ક મેનેજરને ઇન્ટરફેસ-સ્તરનું કન્ફિગરેશન રાખવા દો, VPN ક્લાયન્ટને એ જ એકીકરણ દ્વારા દરેક લિંકના DNS અને ડોમેન્સ ફાળો આપવા દો, અને ફાઇલ સીધી લખતી ત્રીજી સ્ક્રિપ્ટ દૂર કરો. systemd-resolved નું દસ્તાવેજીકરણ તે જે મોડ્સને સમર્થન આપે છે અને દરેક /etc/resolv.conf માં શું દર્શાવે છે તે જણાવે છે. તમારે કેટલી નીતિ રાખવી છે તેની સાથે મેળ ખાતો મોડ પસંદ કરો. જો સ્પ્લિટ DNS મહત્ત્વનું હોય, તો દરેક લિંકના ડોમેન્સ સાથેનું stub ગોઠવણ તેને જાળવી રાખે છે, જ્યારે upstream સર્વરો ફાઇલમાં નકલ કરતો મોડ તેને ચૂપચાપ સપાટ કરી નાખે છે.

ફરીથી જોડાણ પછી ચકાસો, સંપાદન પછી નહીં

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

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

ડિપ્લોયમેન્ટ નોંધોમાં માલિક, બેકએન્ડ અને સિમ્બોલિક લિંક મોડ નોંધો. એ એક જ પરિચ્છેદ ભાવિ પેકેજ અપગ્રેડને બનાવમાંથી સમીક્ષા બિંદુમાં ફેરવે છે, અને આગલી વ્યક્તિને chattr આદેશથી એ જ સંઘર્ષ ફરી શોધવાથી રોકે છે.