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 ਟਨਲਿੰਗ ਕਲਾਇੰਟ ਵੱਲੋਂ DNS ਸੂਚੀ ਮੁੜ ਲਿਖਣ 'ਤੇ ਵੀ Windows resolver ਰਾਹੀਂ ਖੋਜ ਫਾਰਵਰਡ ਕਰਦੀ ਹੈ। ਇਹ ਸਰਵਵਿਆਪੀ ਨਹੀਂ: ਕੁਝ ਫਿਲਟਰ ਡਰਾਈਵਰ ਅਜੇ ਵੀ ਮਿਰਰ ਪਾਥ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ Hyper-V ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਨੂੰ ਸਪਸ਼ਟ ਇਜਾਜ਼ਤ ਲੱਗ ਸਕਦੀ ਹੈ। Microsoft ਦੀ WSL ਨੈੱਟਵਰਕਿੰਗ ਗਾਈਡ ਉਹ ਪੰਨਾ ਹੈ ਜੋ ਨਵੇਂ ਲਈ ਲਿਖੀ ਵਿਧੀ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਬਿਲਡ ਨਾਲ ਮਿਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ।
ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਤਿੰਨ ਚੀਜ਼ਾਂ ਟੈਸਟ ਕਰੋ
ਹਰ ਮਸ਼ੀਨ ਲਈ ਇੱਕ ਮਕੈਨਿਜ਼ਮ ਚੁਣੋ ਅਤੇ ਲਿਖ ਕੇ ਰੱਖੋ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਬੁਰੀ ਤਰ੍ਹਾਂ ਮਿਲਦੇ ਹਨ। ਮਿਰਰ ਮੋਡ ਉੱਤੇ sidecar ਫਾਰਵਰਡਿੰਗ ਦੁੱਗਣੀ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ .wslconfig ਵਿੱਚ ਪੁਰਾਣੀ sidecar ਐਂਟਰੀ ਵਾਲਾ ਮਿਰਰ ਹੋਸਟ ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਪਹਿਲਾਂ ਨਹੀਂ।
ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣਿਆ ਹੋਵੇ, ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਅੰਦਰਲੀਆਂ ਉਹੀ ਤਿੰਨ ਬੇਨਤੀਆਂ ਹਨ: ਅੰਦਰੂਨੀ ਨਾਮ, ਜਨਤਕ ਨਾਮ ਅਤੇ ਕੱਚਾ ਪਤਾ। ਫਿਰ ਟਨਲ ਡਿਸਕਨੈਕਟ ਤੇ ਮੁੜ ਕਨੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਤੇ wsl --shutdown ਤੋਂ ਬਾਅਦ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਹਰਾਓ। ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਨਾਮ ਦਾ ਫੇਲ ਹੋਣਾ resolver ਨੀਤੀ ਹੈ; ਅੰਦਰੂਨੀ ਅਤੇ ਜਨਤਕ ਨਾਮ ਇਕੱਠੇ ਫੇਲ ਹੋਣਾ ਜਦੋਂ ਪਤਾ ਚੱਲਦਾ ਹੈ ਤਾਂ ਵੀ resolver ਨੀਤੀ ਹੈ; ਸਭ ਕੁਝ ਫੇਲ ਹੋਣਾ ਪਾਥ ਹੈ।
ਜੇ ਇੱਕ ਅੰਦਰੂਨੀ ਹੋਸਟ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਬਾਕੀ ਚੱਲਦੇ ਹਨ, ਤਾਂ resolver ਵੱਲ ਦੇਖਣਾ ਬੰਦ ਕਰੋ ਅਤੇ ਉਸ ਪ੍ਰੀਫਿਕਸ ਲਈ ਗੁੰਮ ਰੂਟ ਲੱਭੋ। ਜੇ ਅਗਲੇ ਮੁੜ ਕਨੈਕਸ਼ਨ ਤੱਕ ਸਭ ਕੁਝ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰਨਟਾਈਮ ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਸੁਧਾਰ ਲੱਭਿਆ ਹੈ, ਅਤੇ ਉਹ ਸਵੈਚਾਲਿਤ ਰੂਪ ਵਿੱਚ ਮੁੜ ਲਾਗੂ ਕਰਨਾ ਜਾਂ ਉੱਪਰਲੇ ਦੋ ਮਕੈਨਿਜ਼ਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਬਦਲਣਾ ਪਵੇਗਾ।