VPN કનેક્ટ થયા પછી WSL2 એ DNS ગુમાવ્યું? બે કારણો
જૂની resolver ફાઇલ અને સ્પર્ધાત્મક રૂટ મેટ્રિક WSL2 ની અંદર એક જ લક્ષણ ઉત્પન્ન કરે છે. બંને બાજુની નોંધ લો, પછી જે ખરેખર તૂટેલી છે તેને સુધારો.
સરનામા પર ping ડિસ્ટ્રિબ્યુશનની અંદર કામ કરે છે, પેકેજ ઇન્સ્ટોલ અને git ખેંચાણ કામ કરતા નથી, અને ભંગાણ ટનલ ઉપર આવ્યા પછી તરત જ દેખાયું. ફક્ત નામો ઉકેલાવાનું બંધ થયું, જે DNS તરફ ઇશારો કરે છે, કનેક્ટિવિટી તરફ નહીં. પેકેજ ફરી ઇન્સ્ટોલ કરવું એ અહીં સૌથી લોકપ્રિય ખોટું પ્રથમ પગલું છે. WSL2 પાસે બરાબર એ જ લક્ષણ બનાવવાના બે સ્વતંત્ર રસ્તા છે, અને બંનેને અલગ સુધારણા જોઈએ.
શા માટે ડિસ્ટ્રિબ્યુશન પોતાનું resolver રાખે છે
Windows નો DNS ક્લાયન્ટ ડિસ્ટ્રિબ્યુશનની અંદર વપરાતો નથી. WSL2 શરૂ થતાં પોતાની resolver ફાઇલ બનાવે છે, જે એક stub સરનામા તરફ દોરે છે જે Windows સહાયક વર્ચ્યુઅલ મશીન માટે વર્ચ્યુઅલ સ્વિચ પર પ્રકાશિત કરે છે.
સામાન્ય નેટવર્ક ફેરફારોમાં આ ગોઠવણ સ્થિર છે કારણ કે તે એક વાર લખાય છે અને ફરી વપરાય છે. જ્યારે ટનલ ક્લાયન્ટ સહાયક વર્ચ્યુઅલ મશીન શરૂ થઈ ગયા પછી હોસ્ટની એડેપ્ટર યાદી ફરી લખે છે ત્યારે આ ગોઠવણ સાચી રહેતી નથી.
ડિસ્ટ્રિબ્યુશનની અંદર કંઈ પણ આ ફેરફાર પર નજર રાખતું નથી, તેથી ફાઇલ એવા સરનામા તરફ દોરતી રહે છે જે કદાચ હવે માર્ગ પર ન હોય. પછીની શોધ પછી પ્રતીક્ષા કરે છે, સમય સમાપ્ત થાય છે, અથવા એવા સર્વર તરફથી જવાબ મળે છે જેણે આંતરિક ઝોન વિશે કદી સાંભળ્યું નથી. અંદરથી resolver ફક્ત જવાબ આપવાનું બંધ કરે છે, અને બધા નામો એકસાથે નિષ્ફળ જાય છે.
પહેલા બંને બાજુના પુરાવા એકત્ર કરો
ડિસ્ટ્રિબ્યુશન શું જુએ છે તે નોંધો, પછી Windows શું જુએ છે તે, કોઈપણ બદલતા પહેલા. બંને દૃશ્યો સાથે મળીને જ નિષ્ફળતાની રીતો અલગ પાડે છે.
ડિસ્ટ્રિબ્યુશનની અંદર, resolver ફાઇલ, રૂટિંગ કોષ્ટક અને એક આંતરિક અને એક જાહેર શોધ છાપો:
ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.comWindows પર, દરેક એડેપ્ટર મુજબ DNS સર્વરો અને મેટ્રિક સાથે IPv4 કોષ્ટક યાદીમાં મૂકો. VPN ક્લાયન્ટ સામાન્ય રીતે WSL2 સબનેટ માટે રૂટ સ્થાપિત કરે છે, અને તેનું મેટ્રિક નક્કી કરે છે કે તે ટ્રાફિક ટનલમાંથી નીકળે છે કે સ્થાનિક રહે છે.
Get-NetAdapter | Get-DnsClientServerAddress
route print -4
રૂટ મેટ્રિક કે જૂની ફાઇલ
પહેલું ભંગાણ જૂની ફાઇલ છે. resolver શરૂઆત વખતની એડેપ્ટર સ્થિતિ માટે લખાયું હતું, અને ટનલે તે સ્થિતિ બદલી. તેનું stub સરનામું હવે પહોંચન બહાર હોઈ શકે છે, અથવા એવા સર્વરનું નામ આપે છે જે આંતરિક ઝોન વિશે કંઈ જાણતું નથી.
બીજું રૂટિંગ સમસ્યા છે. જ્યારે VPN WSL2 સબનેટને આવરી લેતો રૂટ ઉમેરે છે હોસ્ટ લિંક રૂટ કરતાં નીચા મેટ્રિક સાથે, ત્યારે સહાયક વર્ચ્યુઅલ મશીનને સંબોધિત પેકેટ ટનલમાં પ્રવેશે છે. પછી ફક્ત DNS જ નહીં, દરેક WSL2 સેવાનો સમય સમાપ્ત થાય છે.
ભેદ પાડતી કસોટીને એક લાઇન ખર્ચ થાય છે. જાહેર resolver જેવું સંખ્યાત્મક સરનામું જો નામો નિષ્ફળ થતાં હોવા છતાં ping ને હજી જવાબ આપે, તો માર્ગ અકબંધ છે અને સમસ્યા DNS છે. આ એ જ કિસ્સો છે જ્યાં resolver બદલવું ન્યાયી છે, અને જ્યાં નથી તે કિસ્સો પણ સ્પષ્ટ થાય છે. જો સંખ્યાત્મક કસોટી પણ નિષ્ફળ જાય, તો સહાયક વર્ચ્યુઅલ મશીને તેનો રૂટ ગુમાવ્યો છે અને કોઈ resolver ફાઇલ તેને સુધારશે નહીં.
રૂટિંગના કિસ્સા માટે, ટનલ એડેપ્ટર પરનું સ્વયં મેટ્રિક દૂર કરો અને તેને WSL2 લિંક રૂટથી ઉપરની સંખ્યા આપો:
Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown
બંધ કરવું મહત્વનું છે. મેટ્રિક બદલવાથી ચાલુ સહાયક વર્ચ્યુઅલ મશીન ફરી લખાતું નથી, તેથી ફેરફાર દેખાય તે પહેલાં ડિસ્ટ્રિબ્યુશન ફરી બનાવવું પડે.
ફાઇલ સભાનપૂર્વક હાથમાં લો
જો રૂટિંગ સાચું છે અને ફક્ત આંતરિક નામો નિષ્ફળ જાય છે, તો દોષ resolver નો છે અને તમે જનરેટર થોભાવી શકો છો. આ જાળવણી ખર્ચ સાથેનો સભાન ફેરફાર છે, બેદરકારીથી લાગુ કરવાનો કોઈ ઉપાય નથી.
ડિસ્ટ્રિબ્યુશનની અંદર જનરેશન બંધ કરતા નેટવર્ક વિભાગ સાથે /etc/wsl.conf બનાવો, પછી resolver ફાઇલ જાતે લખો, પહેલા કોર્પોરેટ સર્વર અને પછી જાહેર વૈકલ્પિક:
[network]
generateResolvConf = falsesearch corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9
ક્રમ મહત્વનો છે. જાહેર resolver આંતરિક નામનો જવાબ આપી શકતું નથી, અને વૈકલ્પિક ફક્ત ઇન્ટરનેટ શોધ માટે છે. ફાઇલ એક વાર તમારી થઈ પછી કંઈ પણ તેને ફરી બનાવતું નથી, તેથી સ્થળાંતર કરતું કોર્પોરેટ resolver એવી અટકચાલ બને છે જે તમારે જ ધ્યાનમાં લેવી પડે.
પહેલા નામો તપાસો, પછી પેકેજ
સિસ્ટમ resolver વડે એક આંતરિક અને એક જાહેર નામ ચકાસો, પછી નિષ્ફળ ગયેલી ક્રિયા ફરી કરો. પેકેજ મેનેજર ક્યારેક પોતાનું resolver વાપરે છે, તેથી કામ કરતું getent તૂટેલી ઇન્સ્ટોલ સાથે પણ રહી શકે છે.
જો તમે ફરી લખવાનું સ્વયંસંચાલિત કરો, તો તેને એક જ પરિણામ આપતું બનાવો: ટનલ ન હોય તો ખાલી સર્વર યાદી લખવાને બદલે પહેલેથી હાજર ફાઇલ રાખો.
getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com
ડિસ્ટ્રિબ્યુશનની અંદરથી કામ કરતી આંતરિક શોધ અને કામ કરતી જાહેર શોધ એ નોંધવા લાયક પરિણામ છે. હોસ્ટ પર લીલું VPN ચિહ્ન બંનેમાંથી એક પણ સાબિત કરતું નથી.