VPN કનેક્ટ થાય ત્યારે WSL કાર્ય હોસ્ટનામ કેમ ગુમાવે છે?
એ જ નામ Windows માં કામ કરે છે અને ટનલ ઊપર થતાં જ WSL ની અંદર નિષ્ફળ જાય છે. રિઝોલ્વર ઉમેરતા પહેલાં પ્લેટફોર્મનો DNS મોડ અને જૂના ઓવરરાઇડ્સ તપાસો.
Windows આંતરિક હોસ્ટને કોઈ ફરિયાદ વિના રિઝોલ્વ કરે છે, અને એ જ નામ ટનલ ઊપર થાય તે ક્ષણે WSL ની અંદર નિષ્ફળ જાય છે. સામાન્ય સુધારો એ છે કે ડિસ્ટ્રિબ્યુશનમાં જાહેર રિઝોલ્વર લખવું, જે સામાન્ય બ્રાઉઝિંગ પાછું લાવે છે અને કાર્ય હોસ્ટનામને અરિઝોલ્વેબલ બનાવે છે. આ એક નિષ્ફળતાને બીજી સાથે બદલે છે અને જે સ્તર ખરેખર તૂટ્યું છે તેને છુપાવે છે. કોઈપણ રિઝોલ્વર લાઇન ઉમેરતા કે દૂર કરતા પહેલાં નક્કી કરો કે ત્રણમાંથી કયું સ્તર નિષ્ફળ જાય છે.
પહેલાં રૂટિંગ નિષ્ફળતાને બાકાત કરો
બંને બાજુએ એ જ સંપૂર્ણ લાયકાત ધરાવતું નામ પૂછો, એકસરખા દેખાતાં બે નામ નહીં. એક જ સ્ટ્રિંગ માટે Windows માં સફળતા અને WSL માં નિષ્ફળતા એ બે રિઝોલ્યુશન માર્ગોની સહી છે, અને બીજું ભાગ્યે જ આ પેટર્ન આટલી સ્વચ્છ રીતે બનાવે છે. જો WSL તેના જાણીતા આંકડાકીય સરનામે પણ સેવા સુધી પહોંચી ન શકે, તો રૂટિંગ કે ફિલ્ટરિંગની સમસ્યા પણ છે. તે સ્થિતિમાં DNS કાર્ય તેને જાહેર કરશે નહીં, અને બપોર ખોટા સ્તરે જશે.
ત્રણ લક્ષણો આમાંનાં મોટા ભાગના કિસ્સાઓ આવરી લે છે, અને દરેક અલગ જગ્યાએ ઇશારો કરે છે. કન્ફિગરેશન ફાઇલ ખોલતા પહેલાં મેળ ખાતી હરોળ વાંચો:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
વચ્ચેની હરોળ લોકો ખોટી વાંચે છે, કારણ કે તેને તોડનારો ફેરફાર અઠવાડિયાં પહેલાં કરાયો હતો અને ત્યારે સફળ લાગતો હતો. ત્રીજી હરોળ લોકો ખોટું નિદાન કરે છે, કારણ કે રિઝોલ્વ થતું નામ નેટવર્ક સ્વસ્થ હોવાનો પુરાવો લાગે છે. બંને હરોળ તમને નીચેના અલગ વિભાગમાં મોકલે છે.
DNS ટનલિંગની ન્યૂનતમ આવૃત્તિ છે
Microsoft WSL નો એક નેટવર્કિંગ મોડ દસ્તાવેજ કરે છે જે વર્ચ્યુઅલાઇઝેશન ચેનલ દ્વારા DNS વિનંતીઓને Windows રિઝોલ્વર સુધી ટનલ કરે છે. સમર્થિત Windows 11 બિલ્ડ્સ પર તે ડિફોલ્ટથી સક્ષમ હોય છે, અને તેથી જ એક જ કોર્પોરેટ નેટવર્ક પરની બે મશીનો અલગ વર્તે છે. ચલ બિલ્ડ નંબર છે, કોર્પોરેટ નીતિ નહીં.
WSL નેટવર્કિંગ માર્ગદર્શિકા તે મોડ અને તેને સમર્થન આપતી આવૃત્તિઓનું વર્ણન કરે છે. આ સુવિધા મહત્વપૂર્ણ છે કારણ કે કોર્પોરેટ DNS નીતિ સામાન્ય રીતે Windows રિઝોલ્વરમાં રહે છે, અને Windows નો માર્ગ વારસામાં મળતું ડિસ્ટ્રિબ્યુશન તેની સાથે નીતિ પણ વારસામાં મેળવે છે. જાહેર રિઝોલ્વરને પૂછતા ડિસ્ટ્રિબ્યુશન પાસે ખાનગી નામ સુધીનો કોઈ માર્ગ નથી, તેનું પોતાનું કન્ફિગરેશન ગમે તેટલું સુઘડ લાગે. તે જ મિકેનિઝમ આખું લક્ષણ સમજાવે છે, અને સમજાવે છે કે જાહેર-રિઝોલ્વર ઉપાય કેમ નિષ્ફળ જાય છે.
કંઈપણ સંપાદિત કરતા પહેલાં બિલ્ડ નંબર વાંચો. નવીન ઇન્સ્ટોલેશનમાંથી કોપી કરેલી સેટિંગ એ પુરાવો નથી કે જૂનું ઇન્સ્ટોલેશન તેને અમલમાં મૂકે છે. ફેરફારની બાજુમાં બિલ્ડ નંબર નોંધો, કારણ કે બે મશીનો વચ્ચેનો તફાવત લગભગ હંમેશા આવૃત્તિ હોય છે, નીતિ નહીં.
જૂના ઓવરરાઇડ્સ પોતે ઉકેલેલી સમસ્યા કરતાં વધુ જીવે છે
જૂની રેસિપીઓ જનરેટ થયેલી રિઝોલ્વર ફાઇલો નિષ્ક્રિય કરતી હતી, નેમસર્વરને હાર્ડકોડ કરતી હતી, અથવા ફાઇલને અપરિવર્તનશીલ એટ્રિબ્યુટથી લોક કરતી હતી. તે ફેરફારો તેમને પ્રેરિત કરનારી કનેક્ટિવિટી સમસ્યા દૂર થયાના ઘણા સમય પછી પણ જ્યાં હતા ત્યાં રહે છે, અને સામાન્ય રીતે એ જ કારણ છે કે નવીન સેટિંગ કંઈ કરતું ન હોય તેમ લાગે છે. તેઓ ડિસ્ટ્રિબ્યુશનની પુનઃસ્થાપના પછી પણ shell પ્રોફાઇલના સ્વરૂપમાં ટકી રહે છે, જે દરેક લોગિન પર ફાઇલ ફરી લખે છે. છેલ્લું શોધવું સૌથી અઘરું છે, કારણ કે જે ફાઇલ દરેક તપાસે છે તેનાથી તે અદૃશ્ય છે.
હાથે લખેલી રિઝોલ્વર ફાઇલ, તેના પર અપરિવર્તનશીલ એટ્રિબ્યુટ, અને તેને ફરી લખતી સ્ટાર્ટઅપ સ્ક્રિપ્ટ શોધો. સંપાદન કરતા પહેલાં અપરિવર્તનશીલ ફ્લેગ તપાસો, કારણ કે લોક કરેલી ફાઇલમાં લખવું પરવાનગીની સમસ્યા જેવું વંચાય તે રીતે નિષ્ફળ જાય છે. પછી shell પ્રોફાઇલ તપાસો, કારણ કે ત્યાંની સ્ક્રિપ્ટ તમારા સુધારાના સેકંડોમાં જૂનું સામગ્રી પાછું લાવે છે.
ઓવરરાઇડ દૂર કરવાના પરિણામો હોય છે, તેથી તમે શું દૂર કર્યું અને કેમ તે નોંધો. જે ડિસ્ટ્રિબ્યુશનને ખરેખર બીજા હેતુ માટે સ્થિર રિઝોલ્વરની જરૂર હોય તે જનરેટ થયેલી ફાઇલ પાછી આવતાં તૂટી જશે.
બે ફાઇલો, બે અલગ ભૂમિકાઓ
બે કન્ફિગરેશન ફાઇલો અલગ જગ્યાએ રહે છે અને અલગ વસ્તુઓ નિયંત્રિત કરે છે, અને તેમને ભેળવી દેવાથી ખોટા સ્તરે લાગુ પડતા સંપાદનો થાય છે. Windows બાજુની ફાઇલ વર્ચ્યુઅલ મશીનના ગુણધર્મો સેટ કરે છે, જ્યારે ડિસ્ટ્રિબ્યુશન બાજુની ફાઇલ નક્કી કરે છે કે તે ડિસ્ટ્રિબ્યુશન પોતાનું રિઝોલ્વર કન્ફિગરેશન કેવી રીતે બનાવે છે. એક પણ બીજાને ઓવરરાઇડ કરતું નથી, તેથી બંનેને સંમત થવું પડે છે.
જે ઇન્સ્ટોલેશન આ સુવિધાને સમર્થન આપે છે તેના માટે Windows બાજુનો ટુકડો ટૂંકો છે. તે બાજુનો આખો ફેરફાર આ જ છે:
[wsl2]
dnsTunneling=trueતે ટુકડો Windows વપરાશકર્તા પ્રોફાઇલમાં આવે છે અને એક ડિસ્ટ્રિબ્યુશનને બદલે વર્ચ્યુઅલ મશીન પર લાગુ પડે છે. ટનલિંગ માટે એ પણ જરૂરી છે કે ડિસ્ટ્રિબ્યુશને રિઝોલ્વર જનરેશન નિષ્ક્રિય ન કર્યું હોય, તેથી ડિસ્ટ્રિબ્યુશન બાજુની ફાઇલે તે વર્તનને એમ જ રહેવા દેવું પડે છે. એકને બીજા વિના બદલો અને મોડ ચૂપચાપ કંઈ કરતું નથી, અને આ સુધારો તૂટેલો હોવાના સમાચાર આપવાની આ સૌથી સામાન્ય રીત છે. એક જ સેશનમાં બંને ફાઇલો તપાસો, કારણ કે અઠવાડિયાંના અંતરે કરાયેલા બે સંપાદનો એવાં બે સંપાદનો છે જે કોઈ આભારી શકે નહીં.
ફરી શરૂ કરો, પછી બંને બાજુથી પૂછો
આ સેટિંગ્સ પર્યાવરણ શરૂ થાય ત્યારે વંચાય છે, તેથી ચાલુ ડિસ્ટ્રિબ્યુશનની અંદરનો નવો shell તેમને ફરી લોડ કરશે નહીં. shell ફરી શરૂ કરવાને બદલે પર્યાવરણ બંધ કરો, અને પહેલાં ચાલુ કામ સાચવો કારણ કે દરેક ડિસ્ટ્રિબ્યુશન તેની સાથે બંધ થાય છે. ફક્ત આ ચૂક જ ફેરફારની કોઈ અસર ન હોવાના મોટા ભાગના અહેવાલો સમજાવે છે.
પછી બંને બાજુએ એ જ પ્રશ્ન પૂછો. આઉટપુટ એ પણ બતાવે છે કે ડિસ્ટ્રિબ્યુશન આખરે કયા રિઝોલ્વર સાથે રહ્યું:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'પ્રથમ આદેશ પર્યાવરણ સમાપ્ત કરે છે, બીજો બતાવે છે કે ડિસ્ટ્રિબ્યુશન હવે કયો રિઝોલ્વર વાપરે છે, અને છેલ્લા બે દરેક બાજુને એ જ પ્રશ્ન પૂછે છે. સેટિંગની સ્થિતિ નહીં, જવાબોની સરખામણી કરો. બંને ફાઇલો સાચી હોવા છતાં સ્વચ્છ પુનઃશરૂઆત પછી પણ નિષ્ફળ જતી ક્વેરી કોર્પોરેટ રિઝોલ્વર નીતિ તરફ ઇશારો કરે છે, અને તે વાતચીતનો માલિક બીજો છે.