VPN ਜੁੜਨ ਤੋਂ ਬਾਅਦ WSL2 ਨੇ DNS ਗੁਆ ਦਿੱਤਾ? ਦੋ ਕਾਰਨ
ਪੁਰਾਣੀ resolver ਫਾਈਲ ਅਤੇ ਮੁਕਾਬਲੇ ਵਾਲਾ ਰੂਟ ਮੈਟ੍ਰਿਕ WSL2 ਦੇ ਅੰਦਰ ਉਹੀ ਲੱਛਣ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਦੋਵੇਂ ਪਾਸੇ ਦਰਜ ਕਰੋ, ਫਿਰ ਜੋ ਸੱਚਮੁੱਚ ਟੁੱਟਿਆ ਹੈ ਉਸਨੂੰ ਠੀਕ ਕਰੋ।
ਪਤੇ ਨਾਲ ping ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਅੰਦਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਪੈਕੇਜ ਇੰਸਟਾਲ ਅਤੇ git ਖਿੱਚਣਾ ਨਹੀਂ, ਅਤੇ ਨੁਕਸ ਟਨਲ ਉੱਪਰ ਆਉਣ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਦਿਖਿਆ। ਸਿਰਫ਼ ਨਾਮ ਹੱਲ ਹੋਣਾ ਬੰਦ ਹੋਇਆ, ਜੋ DNS ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਕਨੈਕਟੀਵਿਟੀ ਵੱਲ ਨਹੀਂ। ਪੈਕੇਜ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਨਾ ਇੱਥੇ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਗਲਤ ਪਹਿਲਾ ਕਦਮ ਹੈ। WSL2 ਕੋਲ ਬਿਲਕੁਲ ਉਹੀ ਲੱਛਣ ਪੈਦਾ ਕਰਨ ਦੇ ਦੋ ਸੁਤੰਤਰ ਤਰੀਕੇ ਹਨ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਵੱਖਰੀ ਮੁਰੰਮਤ ਚਾਹੀਦੀ ਹੈ।
ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਆਪਣਾ resolver ਕਿਉਂ ਰੱਖਦਾ ਹੈ
Windows ਦਾ DNS ਕਲਾਇੰਟ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਅੰਦਰ ਵਰਤਿਆ ਨਹੀਂ ਜਾਂਦਾ। WSL2 ਸ਼ੁਰੂ ਹੁੰਦਿਆਂ ਆਪਣੀ resolver ਫਾਈਲ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ Windows ਵੱਲੋਂ ਸਹਾਇਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਲਈ ਵਰਚੁਅਲ ਸਵਿੱਚ ਉੱਤੇ ਪ੍ਰਕਾਸ਼ਿਤ stub ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।
ਇਹ ਬੰਦੋਬਸਤ ਆਮ ਨੈੱਟਵਰਕ ਬਦਲਾਵਾਂ ਵਿੱਚ ਸਥਿਰ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਵਾਰ ਲਿਖੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਜਦੋਂ ਟਨਲ ਕਲਾਇੰਟ ਸਹਾਇਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਪਹਿਲਾਂ ਹੀ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੋਸਟ ਦੀ ਅਡੈਪਟਰ ਸੂਚੀ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ ਤਾਂ ਇਹ ਬੰਦੋਬਸਤ ਸਹੀ ਨਹੀਂ ਰਹਿੰਦੀ।
ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਅੰਦਰ ਕੁਝ ਵੀ ਇਸ ਬਦਲਾਅ ਦੀ ਨਿਗਰਾਨੀ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਫਾਈਲ ਉਸ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ ਜੋ ਹੁਣ ਰਸਤੇ ਉੱਤੇ ਨਾ ਹੋਵੇ। ਅਗਲੀ ਲੁੱਕਅੱਪ ਫਿਰ ਉਡੀਕਦੀ ਹੈ, ਸਮਾਂ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਅਜਿਹੇ ਸਰਵਰ ਤੋਂ ਜਵਾਬ ਮਿਲਦਾ ਹੈ ਜਿਸਨੇ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਬਾਰੇ ਕਦੇ ਨਹੀਂ ਸੁਣਿਆ। ਅੰਦਰੋਂ 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 ਆਈਕਨ ਦੋਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।