WSL2 કોર્પોરેટ VPN વારસામાં લેતું નથી, અને એ જ ખામી છે
WSL2 પોતાના વર્ચ્યુઅલ નેટવર્કમાં ચાલે છે અને હોસ્ટનો VPN સ્ટેક ક્યારેય વારસામાં લેતું નથી. resolv.conf સંપાદિત કરતાં પહેલાં નામની નિષ્ફળતાઓને પાથની નિષ્ફળતાઓથી અલગ કરો.
આંતરિક વિકી Edge માં લોડ થાય છે, જ્યારે ડિસ્ટ્રિબ્યુશનની અંદર git clone સમયસીમા વટાવે છે. એ એક અવલોકન સામાન્ય રીતે «VPN WSL2 ને અવરોધે છે» તરીકે વાંચવામાં આવે છે, અને પછીનો કલાક /etc/resolv.conf સંપાદિત કરવામાં જાય છે. વધુ ઉપયોગી વાંચન એ છે કે WSL2 પાસે હોસ્ટનો નેટવર્ક પાથ ક્યારેય નહોતો: તે પોતાના એડેપ્ટર, પોતાના રૂટ અને Windows તેના માટે બનાવેલી resolver ફાઇલ સાથે યુટિલિટી VM માં ચાલે છે. આગળનું બધું એના પર આધાર રાખે છે કે એ ત્રણમાંથી ખરેખર કઈ વસ્તુ તમારી પાસે નથી.
VM પાસે પોતાનો સ્ટેક, મેટ્રિક અને resolver છે
ડિફોલ્ટ NAT મોડમાં, ડિસ્ટ્રિબ્યુશન વર્ચ્યુઅલ સ્વિચ પાછળ બેસે છે અને હોસ્ટ દ્વારા ઇન્ટરનેટ સુધી પહોંચે છે, પણ હોસ્ટના એડેપ્ટર જોતું નથી. ip addr ખાનગી સરનામા સાથે એક ઇન્ટરફેસ દર્શાવે છે, ip route તે સ્વિચ દ્વારા ડિફોલ્ટ રૂટ દર્શાવે છે, અને /etc/resolv.conf Windows એ પસંદ કરેલા stub resolver તરફ ઇશારો કરતી જનરેટ થયેલી ફાઇલ છે. Windows બાજુએ VPN ક્લાયન્ટ શરૂ થવાથી એમાંથી કંઈ બદલાતું નથી.
એટલે જ «બ્રાઉઝર કામ કરે છે» એટલું ઓછું સાબિત કરે છે. બ્રાઉઝર હોસ્ટનો સ્ટેક, ટનલ અને હોસ્ટની resolver નીતિ વાપરે છે. તમારો શેલ બીજો સ્ટેક વાપરે છે જે સંજોગવશાત્ ભૌતિક નેટવર્ક કાર્ડ વહેંચે છે. સારા કિસ્સામાં તેઓ સહમત થાય છે અને ત્યારે જ અલગ પડે છે જ્યારે VPN ફિલ્ટર સ્થાપિત કરે, DNS યાદી ફરીથી લખે અથવા વર્ચ્યુઅલ સ્વિચના સબનેટ માટે રૂટ ઉમેરે.
તમે કઈ દુનિયામાં છો તે બે પરીક્ષણો નક્કી કરે છે, અને તે ડિસ્ટ્રિબ્યુશનની અંદર ચલાવવા પડે છે:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confશાબ્દિક સરનામું જવાબ આપે ત્યારે નામ નિષ્ફળ જવું એ resolver સમસ્યા છે. નામ અને સરનામાં સાથે નિષ્ફળ જવું એ પાથની સમસ્યા છે, અને resolver સંપાદન તેને સ્પર્શ પણ કરશે નહીં. પછી Windows બાજુના પુરાવા આવે છે: Get-NetAdapter | Get-DnsClientServerAddress અને route print -4 દર્શાવે છે કે ટનલે તમારું VM જે સબનેટમાં રહે છે તે કબજે કર્યું છે કે નહીં.
પહેલી ભ્રાંતિ: કોર્પોરેટ DNS સર્વર તેને ઠીક કરે છે
resolver ફાઇલ સંપાદિત કરવી એ પરંપરાગત સલાહ છે, અને તે અડધા સમયે સાચી હોય છે. જ્યારે સાચી હોય છે ત્યારે ચોક્કસ કારણસર સાચી હોય છે: જનરેટ થયેલી ફાઇલ એવા resolver તરફ ઇશારો કરે છે જે ફક્ત જાહેર નામો જાણે છે, તેથી intranet.example.internal માટેની ક્વેરી પાથ ઠીક હોવા છતાં અસ્તિત્વમાં નથી તેમ પાછી આવે છે.
VPN ના સર્વરને પિન કરવાનો અર્થ છે Windows ને ફાઇલ ફરી બનાવવાથી રોકવું, કારણ કે તમે હાથે લખો તે કોઈપણ ફાઇલ આગલી શરૂઆતમાં બદલાઈ જાય છે:
[network]
generateResolvConf = falseતેને /etc/wsl.conf તરીકે સાચવો, Windows થી wsl --shutdown ચલાવો, પછી ડિસ્ટ્રિબ્યુશન શરૂ કરો અને /etc/resolv.conf લખો જેમાં ટનલના સર્વર પહેલા અને જાહેર resolver ફક્ત બેકઅપ તરીકે હોય. આ જાળવણી ખર્ચ સાથેનો ટકાઉ ફેરફાર છે: ફાઇલ હવે હોસ્ટને અનુસરતી નથી, તેથી કોર્પોરેટ DNS સરનામાં બદલાય ત્યારે ડિસ્ટ્રિબ્યુશન જૂનાં જ પૂછતું રહે છે. કોઈકે એ ફાઇલનો માલિક બનવું પડે.
જ્યારે નિષ્ફળતા વધુ વ્યાપક હોય ત્યારે પણ તે કંઈ કરતું નથી. જો curl 1.1.1.1 પર સમયસીમા વટાવે, તો ટનલ ક્લાયન્ટ વર્ચ્યુઅલ સ્વિચ ફિલ્ટર કરી રહ્યું છે અથવા VM ના સબનેટને ટનલમાં મોકલી રહ્યું છે, અને સાચો resolver તમને ફક્ત એવાં નામ આપે છે જ્યાં હજી પહોંચી શકાતું નથી.
બીજી ભ્રાંતિ: મેટ્રિક ફેરફાર ટકી રહે છે
જ્યારે નામ ઉકેલાય છે પણ ટ્રાફિક ભૌતિક એડેપ્ટર થી નીકળે છે, ત્યારે ઇન્ટરફેસ મેટ્રિક્સ લિવર છે. VPN એડેપ્ટરને ઊંચો ખર્ચ અને WSL સ્વિચને નીચો ખર્ચ આપો:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1પછી યાદ રાખો કે ઘણા ક્લાયન્ટ બિલ્ડમાં ટનલ એડેપ્ટર દરેક કનેક્શન પર ફરી બનાવાય છે અને મેટ્રિક તેના ડિફોલ્ટ પર પાછી આવે છે. એકવારનો આદેશ એ સુધારો છે જે ચૂપચાપ સમાપ્ત થાય છે, સામાન્ય રીતે સપ્તાહાંત દરમિયાન, અને ટિકિટ «ગયા અઠવાડિયે કામ કરતું હતું» સાથે પાછી આવે છે. VPN ઘટનાથી શરૂ થતું નિર્ધારિત કાર્ય, અથવા વપરાશકર્તા કનેક્ટ થયા પછી ચલાવે તે સ્ક્રિપ્ટ, આ સુધારાનું પ્રામાણિક સંસ્કરણ છે.
એ જ સમાપ્તિ એક જિદ્દી પ્રીફિક્સ માટે ઉમેરાયેલા હોસ્ટ રૂટને પણ લાગુ પડે છે. નિદાન તરીકે તે મૂલ્યવાન છે, કારણ કે તે કહે છે કે સમસ્યા એક ગંતવ્ય છે કે આખો પાથ, પણ તે આર્કિટેક્ચર નથી.
ત્રીજી ભ્રાંતિ: એક સુધારો દરેક Windows બિલ્ડને આવરી લે છે
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit એ sidecar પેટર્ન છે: એક નાનું ડિસ્ટ્રિબ્યુશન હોસ્ટ બાજુનો પાથ ધરાવે છે અને વર્ચ્યુઅલ સોકેટ દ્વારા બીજા ડિસ્ટ્રિબ્યુશન માટે ફોરવર્ડ કરે છે, તેથી એપ્લિકેશન ટ્રાફિક ફિલ્ટર થયેલા સ્વિચ પર નિર્ભર રહેવાનું બંધ કરે છે. તેને સ્ટોક પાથ કામ કરવો જરૂરી છે, એટલે કે networkingMode અને dnsTunneling ઓવરરાઇડ %UserProfile%\.wslconfig માંથી દૂર કરવા, દરેક કાર્યકારી ડિસ્ટ્રિબ્યુશનમાં generateResolvConf = true પુનઃસ્થાપિત કરવું અને લોગિન પર સેવા શરૂ કરવી.
મિરર્ડ મોડ Windows 11 22H2 અને પછીના સંસ્કરણોમાં બિલ્ટ-ઇન વિકલ્પ છે, અને તે એક સેટિંગ ઉપરાંત એક શટડાઉન છે:
[wsl2]
networkingMode=mirroredડિસ્ટ્રિબ્યુશનની અંદર ip addr પછી હોસ્ટના એડેપ્ટરની યાદી આપે છે, ટનલ તેમની વચ્ચે દેખાઈ શકે છે, અને DNS ટનલિંગ Windows resolver દ્વારા લુકઅપ ફોરવર્ડ કરે છે ત્યારે પણ જ્યારે ક્લાયન્ટ DNS યાદી ફરીથી લખે છે. તે સાર્વત્રિક નથી: કેટલાક ફિલ્ટર ડ્રાઇવર હજી મિરર્ડ પાથ છોડી દે છે, અને Hyper-V ફાયરવોલ નિયમોને સ્પષ્ટ પરવાનગીની જરૂર પડી શકે છે. Microsoft ની WSL નેટવર્કિંગ માર્ગદર્શિકા એ પૃષ્ઠ છે જે નવીન માટે લખાયેલી રેસીપી લાગુ કરતાં પહેલાં તમારા બિલ્ડ સાથે તપાસવું જોઈએ.
દરેક ફેરફાર પછી ત્રણ વસ્તુ ચકાસો
દરેક મશીન માટે એક મિકેનિઝમ પસંદ કરો અને લખી રાખો, કારણ કે બંને ખરાબ રીતે ભળે છે. મિરર્ડ મોડ ઉપર sidecar ફોરવર્ડિંગ બમણું કરે છે, અને .wslconfig માં જૂની sidecar એન્ટ્રી સાથેનું મિરર્ડ હોસ્ટ અપગ્રેડ પછી નિષ્ફળ જવાનું વલણ ધરાવે છે, પહેલાં નહીં.
તમે જે પણ પસંદ કર્યું હોય, સ્વીકૃતિ પરીક્ષણ ડિસ્ટ્રિબ્યુશનની અંદરની એ જ ત્રણ વિનંતીઓ છે: આંતરિક નામ, જાહેર નામ અને કાચું સરનામું. પછી ટનલ ડિસ્કનેક્ટ અને ફરી કનેક્ટ કર્યા પછી અને wsl --shutdown પછી તેમને પુનરાવર્તિત કરો. ફક્ત આંતરિક નામ નિષ્ફળ જવું એ resolver નીતિ છે; આંતરિક અને જાહેર નામ સાથે નિષ્ફળ જવું જ્યારે સરનામું કામ કરે છે તો પણ resolver નીતિ છે; બધું નિષ્ફળ જવું એ પાથ છે.
જો એક આંતરિક હોસ્ટ નિષ્ફળ જાય જ્યારે બાકીના કામ કરે, તો resolver તરફ જોવાનું બંધ કરો અને તે પ્રીફિક્સ માટે ગુમ થયેલો રૂટ શોધો. જો બધું આગલા પુનઃકનેક્શન સુધી કામ કરે, તો તમે રનટાઇમ સ્થિતિ પર આધારિત સુધારો શોધ્યો છે, અને તેને આપોઆપ ફરી લાગુ કરવો પડશે અથવા ઉપરના બે મિકેનિઝમમાંથી એકથી બદલવો પડશે.