WSL 2 માં resolv.conf: VPN કનેક્ટ થાય ત્યારે DNS બંધ પડે છે

ડિસ્ટ્રિબ્યુશનની અંદર બ્રાઉઝિંગ કામ કરે છે, અને ટનલ ઉપર આવતાં જ પહેલું આંતરિક હોસ્ટનામ નિષ્ફળ જાય છે. પ્રતિક્રિયા એ છે કે જાહેર રિઝોલ્વર ઉમેરવું, જે ઇન્ટરનેટ પાછું લાવે છે અને બાકીના દિવસ માટે કોર્પોરેટ નામ અગમ્ય બનાવે છે. WSL 2 માં, /etc/resolv.conf કન્ફિગરેશન નહીં પણ જનરેટ થયેલું આઉટપુટ છે, અને એ જ મિકેનિઝમ સમજવા લાયક છે. ઉપાય વધુ સારું રિઝોલ્વર નથી, ફાઇલની માલિકી છે.

ફાઇલ જનરેટ થાય છે, કન્ફિગર થતી નથી

WSL 2 સ્ટાર્ટઅપ વખતે તે ક્ષણે દેખાતા Windows એડપ્ટરમાંથી ફાઇલ લખે છે, અને ઉપર એમ કહેતી ટિપ્પણી છાપે છે. પછી જ્યારે VPN ક્લાઇન્ટ એડપ્ટર ઉમેરે છે અથવા ફરી લખે છે, ત્યારે ડિસ્ટ્રિબ્યુશન જરૂરી નથી કે કંઈ પણ ફરી બનાવે, અને ફાઇલ એવા નેટવર્કનું વર્ણન કરતી રહે છે જે હવે અસ્તિત્વમાં નથી.

બીજી નિષ્ફળતાની રીત વધુ શાંત છે: WSL ફક્ત કેટલાક એડપ્ટરમાંથી સર્વર કોપી કરી શકે છે. જો ફિઝિકલ એડપ્ટરમાં પહેલેથી IPv6 રિઝોલ્વર હોય, તો VPN એડપ્ટર પૂરા પાડતા IPv4 સર્વર ઉમેરવાને બદલે કાઢી નાખી શકાય છે, અને ફાઇલ પૂર્ણ દેખાય છે જ્યારે તે બરાબર એ જ સર્વર છોડી દે છે જે આંતરિક નામોનો જવાબ આપે છે.

Windows ના દૃશ્યની Linux ના દૃશ્ય સાથે સરખામણી કરો

સંપાદન પહેલાં બંને બાજુ વાંચો. ડિસ્ટ્રિબ્યુશનની અંદર જુઓ કે ફાઇલમાં શું છે અને તે સામાન્ય ફાઇલ છે કે લિંક. Windows પર દરેક એડપ્ટરનું રિઝોલ્વર સૂચિબદ્ધ કરો, જે એડપ્ટર VPN એ બનાવ્યું છે તે સહિત:

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

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

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

જનરેશન બંધ કરો અને તમારી પોતાની ફાઇલ લખો

એક દસ્તાવેજીકૃત સેટિંગ WSL ને ફાઇલ ફરી લખતું અટકાવે છે, અને તે /etc/wsl.conf માં રહેલું છે. એ ફાઇલમાં નેટવર્ક વિભાગ ઉમેરો:

[network]
generateResolvConf = false

પછી Windows થી wsl --shutdown વડે ડિસ્ટ્રિબ્યુશન સમાપ્ત કરો અને ફરી શરૂ કરો. જો માર્ગ સામાન્ય ફાઇલ નહીં પણ સિમ્બોલિક લિંક હોય, તો તમારું પોતાનું સામગ્રી લખતાં પહેલાં લિંક દૂર કરો, કારણ કે લિંક દ્વારા લખવાથી આગલી શરૂઆતમાં જનરેટ થયેલું લક્ષ્ય ફરી બની શકે છે. તે ક્ષણથી ફાઇલ તમારી છે અને કંઈ પણ તેને ફરી લખતું નથી.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

શોધ ડોમેન વિના, અયોગ્ય હોસ્ટનામ જાહેર મૂળ સાથે પૂર્ણ થાય છે અને ‘એવું કોઈ ડોમેન નથી’ તરીકે પાછું આવે છે. timeout મૃત પ્રથમ સર્વરને દરેક લુકઅપ અટકાવતું અટકાવે છે, attempts એક લુકઅપ કેટલા પ્રયાસ વાપરે તે મર્યાદિત કરે છે, અને rotate ફરી પ્રયાસોને હંમેશા ઉપરથી શરૂ કરવાને બદલે ફેલાવે છે. સોદો એ છે કે ફાઇલ હવે એવા VPN ને અનુસરતી નથી જેનું રિઝોલ્વર સરનામું સત્રો વચ્ચે બદલાય છે.

ખસતા રિઝોલ્વર સાથે વ્યવહાર કરો, પછી ચકાસો

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

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

પેકેટ નહીં, નામ સાથે પરીક્ષણ કરો: getent hosts sensor-access0.corp.example રિઝોલ્વર સ્ટેકમાંથી પસાર થાય છે, જ્યારે ping કેશ કરેલા અથવા શબ્દશઃ સરનામા સામે સફળ થઈ શકે છે. પછી ડિસ્કનેક્ટ અને ફરી કનેક્ટ પછી પુનરાવર્તન કરો, કારણ કે એક વાર કામ કરીને ફરી શરૂ થતાં ફરી જનરેટ થતું સેટિંગ કદી સુધારાયું ન હતું. પહેલાનું સામગ્રી સાચવો અને નોંધો કે તે મશીન પર માર્ગ કઈ ઘટકની માલિકીનો છે, જેથી આગલું પરિવર્તન પુરાવા સાથે શરૂ થાય.