resolv.conf સંપાદિત કરવાથી VPN ડિસ્કનેક્ટ થયા પછી DNS ઠીક થતું નથી

તમે VPN ડિસ્કનેક્ટ કરો છો, ping 1.1.1.1 હજી જવાબ આપે છે, અને દરેક નામ લુકઅપ પૃષ્ઠ આખરે હાર માને તે પહેલાં લટકી જાય છે। પછી cat /etc/resolv.conf એવો નેમસર્વર દેખાડે છે જે કદી ફક્ત ટનલની અંદર જ હતો, સામાન્ય રીતે યાદીમાં પહેલો। એ લીટી કાઢી નાખવાથી લગભગ દસ મિનિટ માટે સુધરેલું લાગે છે, જ્યાં સુધી સસ્પેન્ડ, Wi-Fi રોમિંગ કે રીસ્ટાર્ટ તેને પાછો ન મૂકે। તમે સંપાદિત કરેલી ફાઇલ એ સેટિંગ નથી; તે લિંક સ્થિતિનું રેન્ડરિંગ છે જેની માલિકી બીજા ઘટક પાસે છે.

એક જૂની એન્ટ્રી દરેક લુકઅપ માટે સેકન્ડો કેમ ખર્ચ કરે છે

glibc રિઝોલ્વર નેમસર્વર યાદીને ક્રમમાં ચાલે છે અને આગલું અજમાવતા પહેલાં ટાઈમઆઉટ પૂરો થવાની રાહ જુએ છે, અને resolv.conf(5) એ યાદીને ત્રણ એન્ટ્રી સુધી મર્યાદિત કરે છે। ટનલ ગયા પછી 10.8.0.1 જેવું ટનલ-બાજુનું રિઝોલ્વર યાદીની ટોચ પર મૂકો, અને દરેક લુકઅપ જવાબ આપતા સર્વર પર પહોંચતા પહેલાં ટાઈમઆઉટની કિંમત ચૂકવે છે। એટલે જ લક્ષણ DNS ભૂલને બદલે મૃત કનેક્શન જેવું લાગે છે: બ્રાઉઝર બ્લોક થાય છે, સમય પૂરો થાય છે અને ક્યારેક કેશ થયેલું સરનામું આપે છે જે પછી જૂનું થઈ જાય છે।

એ પણ સમજાવે છે કે ફરિયાદ «ઇન્ટરનેટ તૂટી ગયું છે» તરીકે કેમ આવે છે। IP સરનામા પર ping સાબિત કરે છે કે લિંક ઠીક છે, જેનાથી ખામી એપ્લિકેશનની જેવી લાગે છે। રિઝોલ્વર યાદી એ પહેલી વસ્તુ છે જે વાંચવી જોઈએ અને છેલ્લી જે સંપાદિત કરવી જોઈએ।

દંતકથા: resolv.conf એ સેટિંગ્સ ફાઇલ છે

બદલતા પહેલાં પૂછો કે આ પાથ ખરેખર શું છે:

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

systemd-resolved હોસ્ટ પર તે 127.0.0.53 તરફ ઈશારો કરતી સ્ટબ ફાઇલની સિમ્બોલિક લિંક છે, અને સાચા સર્વર resolvectl જે છાપે છે તે દરેક-લિંક સ્થિતિમાં રહે છે। NetworkManager હોસ્ટ પર તે એવી ફાઇલ હોઈ શકે જે NetworkManager સક્રિય કનેક્શનમાંથી લખે છે। કેટલાક વેન્ડર ક્લાયન્ટમાં તે સાદી ફાઇલ છે જે કનેક્ટ થતી વખતે ત્યાં જ ફરી લખાય છે અને, જો તમે નભાગ્યા હોવ તો, ડિસ્કનેક્ટ થતી વખતે કદી પુનઃસ્થાપિત થતી નથી। એ ત્રણ અલગ માલિકો છે, અને પહેલી બેને હાથે સંપાદિત કરવાથી કાં તો કંઈ થતું નથી કાં તો આગલી નેટવર્ક ઘટના સુધી ટકે છે।

resolvectl status એ જ દૃશ્ય છે જે સાચું કહે છે: દરેક લિંક માટે DNS સર્વર, રૂટિંગ ડોમેન, અને ટનલ લિંક હજી છે કે નહીં। resolvectl query example.com આગળ જાય છે અને બતાવે છે કે કઈ ઇન્ટરફેસે જવાબ આપ્યો। ફાઇલને અડકતા પહેલાં બંને વાપરો, અને ધ્યાનમાં રાખો કે પોતાનું સુરક્ષિત DNS ધરાવતું બ્રાઉઝર આ બધું અવગણે છે।

કંઈ પણ સંપાદિત કરતા પહેલાં માલિક શોધો

સામાન્ય રીતે ત્રણ ઘટકો એક જ સેટિંગ માટે સ્પર્ધા કરે છે: systemd-resolved, NetworkManager અને VPN ક્લાયન્ટે જે ઇન્સ્ટોલ કર્યું હોય તે। પહેલાં જીવંત એકને ઓળખો:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

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

ક્લાયન્ટે છોડેલી લિંક સ્થિતિ સાફ કરો

માર્યા ગયેલો ક્લાયન્ટ તેનો ક્લીનઅપ હૂક ચલાવી શકતો નથી। SIGKILL બિલકુલ પકડી શકાતું નથી, જ્યારે SIGINT અને SIGTERM પકડી શકાય છે, એટલે બળજબરીથી માર્યા પછી «બસ અટકી ગયેલી» ટનલ ઘણી વાર ઇન્ટરફેસ નોંધણી અને રિઝોલ્વર એન્ટ્રી બંને જગ્યાએ રહેવા દે છે। ચોક્કસ PID શોધો અને સિગ્નલ ફક્ત તેને મોકલો:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

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

resolvectl revert એ તે લિંકની રનટાઇમ DNS રૂપરેખા રીસેટ કરે છે, જે રિઝોલ્વર રીસ્ટાર્ટ કરવા કરતાં સાંકડું અને ગ્લોબલ ફાઇલ સંપાદિત કરવા કરતાં ઘણું સાંકડું છે। જો ટનલ લિંક સંપૂર્ણ જતી રહી હોય, તો systemctl restart NetworkManager કનેક્શન સ્થિતિ ફરી બનાવે છે અને સ્રોત થ્રેડો વારંવાર આ પગલા પર જ પાછા આવે છે। Restart=always ધરાવતી સેવા મેનેજર પર ધ્યાન રાખો, કારણ કે તે માર્યા ગયેલા ક્લાયન્ટને અને તેની DNS સેટિંગ્સને સીધું પાછું મૂકી શકે છે।

બીજી દિશા: ધકેલાયેલું DNS જે કદી પહોંચ્યું નહીં

જૂની એન્ટ્રીનું પ્રતિબિંબ એ ટનલ છે જેમાં કોઈ પણ વપરાયોગ્ય રિઝોલ્વર નથી। પ્રોફાઇલમાં DNS વિકલ્પ એ વિનંતી છે; કનેક્શન સંભાળતા ઘટકે તેને રિઝોલ્વરને સોંપવી પડે। જો લોગ બતાવે કે સર્વર મળ્યું પણ ટનલ લિંક કોઈ DNS સેટિંગ ધરાવતી નથી, તો ખૂટતું ઇન્ટિગ્રેશન છે, સર્વર નહીં।

સોંપણી હાથે કરીને ચકાસો, જે «સર્વર ખોટું છે» અને «કોઈએ તેને લાગુ કર્યું નથી» વચ્ચે ભેદ પાડે છે:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

બધું પકડતું રૂટિંગ ડોમેન દરેક નામને તે લિંક પર મોકલે છે, જે સંપૂર્ણ ટનલ ક્લાયન્ટ ઈચ્છે છે અને જે સ્પ્લિટ DNS ન વાપરવું જોઈએ। આ સેટિંગ્સ આગલા કનેક્શન પર અદૃશ્ય થાય છે। NetworkManager માં તેમને કાયમી બનાવવા માટે સ્વચાલિત DNS બંધ કરો, કનેક્શન પર સર્વર સેટ કરો અને ડોમેન ઉમેરો:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

એવી કંપની ટનલ માટે જેને ફક્ત આંતરિક નામોના જવાબ આપવા જોઈએ, તે ઝોનને બધું પકડતાને બદલે શરૂઆતના ટિલ્ડે સાથે યાદીમાં મૂકો, જેથી જાહેર નામો સ્થાનિક રિઝોલ્વર વાપરતા રહે।

વર્કઅરાઉન્ડ જે આગલું વિતંડ થઈ જાય છે

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

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

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