ਕਲੋਨ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ, ਵਸਤੂਆਂ ਦੀ ਗਿਣਤੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਕਈ ਮਿੰਟ ਕੁਝ ਨਹੀਂ ਹਿਲਦਾ। Windows ਦੱਸਦਾ ਹੈ ਕਿ VPN ਜੁੜਿਆ ਹੈ, ਹੋਸਟਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸੇ ਮਸ਼ੀਨ ਦਾ ਬ੍ਰਾਊਜ਼ਰ ਉਹੀ ਰਿਪੋਜ਼ਟਰੀ ਪੰਨਾ ਬਿਨਾਂ ਮੁਸ਼ਕਲ ਲੈ ਆਉਂਦਾ ਹੈ। ਇਹ ਸੁਮੇਲ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਵੱਲ ਨਹੀਂ, ਪੈਕੇਟ ਦੇ ਆਕਾਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਆਕਾਰ ਦਾ ਸਵਾਲ ਦੋ ਥਾਵਾਂ 'ਤੇ ਪੁੱਛਣਾ ਪਵੇਗਾ ਕਿਉਂਕਿ WSL2 ਕੋਲ ਆਪਣਾ MTU ਵਾਲਾ ਆਪਣਾ Linux ਇੰਟਰਫੇਸ ਹੈ। ਇੱਕ ਸੰਖਿਆ ਮਾਰਗ ਦੇ Windows ਪਾਸੇ ਦੀ ਹੈ, ਦੂਜੀ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੀ, ਅਤੇ ਸਿਰਫ਼ VPN ਅਡੈਪਟਰ ਪੜ੍ਹਨ ਨਾਲ ਅੱਧਾ ਮਾਰਗ ਬਿਨਾਂ ਜਾਂਚ ਰਹਿ ਜਾਂਦਾ ਹੈ।

ਤਿੰਨ ਸੰਕੇਤ ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੋਰਨਾਂ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹਨ

ਪਹਿਲਾ ਸੰਕੇਤ ਆਕਾਰ ਹੈ: ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਛੋਟਾ ਵਟਾਂਦਰਾ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਵੱਡਾ ਸਥਾਨਾਂਤਰਣ ਤਰੱਕੀ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਦੂਜਾ ਸਮਰੂਪਤਾ ਹੈ: ਉਹੀ ਰਿਪੋਜ਼ਟਰੀ ਅਤੇ ਉਹੀ ਟਰਾਂਸਪੋਰਟ ਫੇਲ ਹੁੰਦੇ ਹਨ ਜਦਕਿ ਉਸੇ ਮਾਰਗ ਦਾ ਦੂਜਾ ਹੋਸਟ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਾਂ ਫੇਲ੍ਹ ਦਿਨ ਦੇ ਸਮੇਂ ਨਾਲ ਨਹੀਂ ਬਲਕਿ ਪੇਲੋਡ ਦੇ ਆਕਾਰ ਨਾਲ ਬਦਲਦੀ ਹੈ। ਤੀਜਾ ਚੁੱਪ ਹੈ: ਕੋਈ ਪ੍ਰਮਾਣਿਕਤਾ ਗਲਤੀ ਨਹੀਂ, ਕੋਈ ਪ੍ਰੌਕਸੀ ਇਨਕਾਰ ਨਹੀਂ, ਕੋਈ ਨਾਮ ਹੱਲ ਫੇਲ੍ਹ ਨਹੀਂ, ਸਿਰਫ਼ ਇੱਕ ਸਥਾਨਾਂਤਰਣ ਜੋ ਕਦੇ ਪੂਰਾ ਨਹੀਂ ਹੁੰਦਾ।

ਇਹ ਤਿੰਨੇ ਮਿਲ ਕੇ ਪੈਕੇਟ-ਆਕਾਰ ਦੀ ਧਾਰਨਾ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦੇ ਹਨ। DNS ਫੇਲ੍ਹ, ਮਿਆਦ ਪੁੱਗਿਆ ਟੋਕਨ, ਅਸਵੀਕਾਰ ਕੀਤੀ SSH ਕੁੰਜੀ ਅਤੇ CONNECT ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਵਾਲੀ ਪ੍ਰੌਕਸੀ—ਹਰ ਇੱਕ ਆਪਣੀ ਗਲਤੀ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਰੁਕਣ ਵਰਗੀ ਨਹੀਂ ਲੱਗਦੀ। ਜਾਂਚ ਦੌਰਾਨ ਉਹੀ ਰਿਪੋਜ਼ਟਰੀ, ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਸਮਾਂ-ਖਿੜਕੀ ਬਣਾਈ ਰੱਖਣਾ ਹੀ ਤੁਲਨਾ ਨੂੰ ਇਮਾਨਦਾਰ ਬਣਾਉਂਦਾ ਹੈ।

ਫੈਸਲਾ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਇੰਟਰਫੇਸਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

ਇੱਕੋ ਸੈਸ਼ਨ ਵਿੱਚ Windows ਦ੍ਰਿਸ਼ ਅਤੇ Linux ਦ੍ਰਿਸ਼ ਇਕੱਠੇ ਕਰੋ, ਅਤੇ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਥਾਂ ਕਿ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਇਸ ਨੂੰ ਢੋਂਦਾ ਹੈ, ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਪਤਾ ਫੜੋ। ਹੇਠਾਂ ਦਿੱਤਾ ਆਦੇਸ਼ ਪਹਿਲਾਂ ਮੰਜ਼ਿਲ ਹੱਲ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਮਾਰਗ ਦੀ ਖੋਜ ਉਸ ਅਸਲ ਸਰਵਰ ਦਾ ਵਰਣਨ ਕਰੇ ਜਿਸ ਨਾਲ ਕਲੋਨ ਸੰਪਰਕ ਕਰਦਾ ਹੈ, ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਦਿਖਾਏ ਨਾਮ ਤੋਂ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਅੱਧੇ ਨੇੜਲੇ ਸਮੇਂ ਵਿੱਚ ਚਲਾਓ, ਕਿਉਂਕਿ VPN ਕੋਸ਼ਿਸ਼ਾਂ ਵਿਚਕਾਰ ਇੰਟਰਫੇਸ ਮੈਟ੍ਰਿਕ ਬਦਲ ਸਕਦਾ ਹੈ।

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Windows ਸ਼ੈੱਲ ਵਿੱਚ ਆਉਟਪੁੱਟ ਪੇਸਟ ਕਰਨ ਦੀ ਥਾਂ Linux ਅੱਧਾ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੇ ਅੰਦਰ ਚਲਾਓ, ਕਿਉਂਕਿ ਇੰਟਰਫੇਸ ਦੇ ਨਾਮ ਅਤੇ ਮਾਰਗ ਚੋਣ ਸਿਰਫ਼ ਉੱਥੇ ਹੀ ਅਰਥ ਰੱਖਦੇ ਹਨ। Windows ਸ਼ੈੱਲ ਤੋਂ ਪੇਸਟ ਕੀਤਾ ਨਤੀਜਾ ਵੱਡੇ ਭਰੋਸੇ ਨਾਲ ਗਲਤ ਸੰਖਿਆਵਾਂ ਦੱਸਦਾ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਪਾਸੇ ਤੋਂ ਡਿਵਾਈਸ, ਚੁਣਿਆ ਮਾਰਗ ਅਤੇ MTU ਨੋਟ ਕਰੋ।

ਸੰਖਿਆ ਛੋਟੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਤੈਅ ਕਰੋ

ਮਾਰਗ ਜਿੰਨਾ ਢੋ ਸਕਦਾ ਹੈ ਉਸ ਤੋਂ ਵੱਡਾ ਇੰਟਰਫੇਸ MTU ਆਪਣੇ ਆਪ ਨੁਕਸ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਮਾਰਗ-MTU ਖੋਜ ਬਿਲਕੁਲ ਇਸੇ ਲਈ ਹੈ। ਫੇਲ੍ਹ ਦਾ ਢੰਗ ਉਦੋਂ ਦਿਖਦਾ ਹੈ ਜਦੋਂ ਖੋਜ ਦਬਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ: ICMP ਸੁਨੇਹੇ ਮਾਰਗ ਵਿੱਚ ਕਿਤੇ ਫਿਲਟਰ ਹੁੰਦੇ ਹਨ, ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਸੀਮਾ ਕਦੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦੀ, ਅਤੇ ਵੱਡੇ ਪੈਕੇਟ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦਕਿ ਛੋਟੇ ਲੰਘ ਜਾਂਦੇ ਹਨ। ਇਹ ਮਾਰਗ ਦਾ ਗੁਣ ਹੈ, Git ਦਾ ਨਹੀਂ। ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਛੋਟੀ ਫਾਈਲ ਉਸ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਵੱਡੀ ਕਦੇ ਪੂਰੀ ਨਹੀਂ ਹੁੰਦੀ।

ਜੇ ਸਬੂਤ ਇਸ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਤਾਂ Linux ਇੰਟਰਫੇਸ ਉੱਤੇ ਅਸਥਾਈ ਬਦਲਾਅ ਸਭ ਤੋਂ ਸਸਤਾ ਟੈਸਟ ਹੈ। ਵਰਤੋਂਯੋਗ ਮਾਰਗ-ਆਕਾਰ ਤੋਂ ਘੱਟ ਮੁੱਲ ਚੁਣੋ, ਪਿਛਲਾ ਨੋਟ ਕਰੋ, ਅਤੇ ਤੁਲਨਾ ਅਰਥਪੂਰਨ ਰਹੇ ਇਸ ਲਈ ਬਾਕੀ ਸਭ ਸਥਿਰ ਰੱਖੋ। ਜੇ ਛੋਟੇ ਮੁੱਲ ਉੱਤੇ ਸਥਾਨਾਂਤਰਣ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਸੰਜੋਗ ਨਹੀਂ, ਨਿਦਾਨ ਹੈ।

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

ਸੈਟਿੰਗ ਕਿੱਥੇ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ, ਇਹ ਤੈਅ ਕਰੋ

ਟੈਸਟ ਤੋਂ ਤਿੰਨ ਵਿਕਲਪ ਨਿਕਲਦੇ ਹਨ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਢੁਕਵਾਂ ਹੁੰਦਾ ਹੈ। ਜੇ ਛੋਟਾ ਮੁੱਲ ਸਥਾਨਾਂਤਰਣ ਸੁਧਾਰਦਾ ਹੈ ਅਤੇ ਮੁੱਲ ਇਸ ਨੈੱਟਵਰਕ ਲਈ ਸੱਚਮੁੱਚ ਲੋੜੀਂਦਾ ਹੈ, ਤਾਂ ਸੈਟਿੰਗ ਨੂੰ ਜੀਵਨ-ਚੱਕਰ ਦਾ ਮਾਲਕ ਚਾਹੀਦਾ ਹੈ: ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਵਿੱਚ ਸਟਾਰਟ ਹੁੱਕ, ਪਲੇਟਫਾਰਮ ਵੱਲੋਂ ਸੰਭਾਲਿਆ ਨੈੱਟਵਰਕ ਕਨਫਿਗਰੇਸ਼ਨ, ਜਾਂ ਦਸਤਾਵੇਜ਼ੀ ਪ੍ਰਕਿਰਿਆ। ਜੇ ਮੁੱਲ ਕੁਝ ਵੀ ਸੁਧਾਰਦਾ ਨਹੀਂ, ਤਾਂ ਇਸਨੂੰ ਵਾਪਸ ਕਰੋ ਅਤੇ ਟਰਾਂਸਪੋਰਟ, ਪ੍ਰੌਕਸੀ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਸਵਾਲਾਂ ਵੱਲ ਪਰਤੋ।

ਸਟਾਰਟ ਹੁੱਕ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਵਰਤੇ ਜਾ ਰਹੇ Windows ਅਤੇ WSL ਸੰਸਕਰਣਾਂ ਅਤੇ ਕਨਫਿਗਰ ਕੀਤੇ ਨੈੱਟਵਰਕਿੰਗ ਮੋਡ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। Windows ਨੈੱਟਵਰਕ ਦਾ ਪ੍ਰਤੀਬਿੰਬ VPN ਦੇ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਨਾਲ ਸੰਵਾਦ ਨੂੰ MTU ਸਮਾਯੋਜਨ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਢੰਗਾਂ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਲਈ ਉਪਾਅ ਤਿਆਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੋਡ ਦੀ ਪਛਾਣ ਕਰੋ। ਇੱਕ ਆਪਰੇਟਰ ਜਾਂ ਇੱਕ VPN ਪਰੋਫਾਈਲ ਲਈ ਢੁਕਵਾਂ ਮੁੱਲ ਅਗਲੇ ਲਈ ਡਿਫਾਲਟ ਨਹੀਂ ਹੈ।

ਜਿਸ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਲੁਭਾਉਣਾ ਟਿਕਾਣਾ ਹੈ: ਹਰ ਇੰਟਰੈਕਟਿਵ ਸ਼ੈੱਲ ਦੀ ਸਟਾਰਟਅੱਪ ਫਾਈਲ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲਾ ਨੈੱਟਵਰਕ ਆਦੇਸ਼, ਜਾਂ ਸਕ੍ਰਿਪਟ ਇੱਕ ਲਾਈਨ ਚਲਾ ਸਕੇ ਇਸ ਲਈ ਪੂਰੀ ip ਬਾਈਨਰੀ ਲਈ ਪਾਸਵਰਡ ਰਹਿਤ sudo। ਦੋਵੇਂ ਨਿਦਾਨ ਨੂੰ ਸਥਾਈ ਖੁਲਾਸੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ ਅਤੇ ਮੂਲ ਸਮੱਸਿਆ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਦੇਖਣਾ ਔਖਾ ਬਣਾ ਦਿੰਦੇ ਹਨ।

ਸਾਫ਼ ਸ਼ੁਰੂਆਤ ਤੋਂ ਬਾਅਦ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਉਲਟਾਓ

ਅਜਿਹਾ ਬਦਲਾਅ ਜੋ ਸਿਰਫ਼ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੇ ਮੁੜ ਚਾਲੂ ਹੋਣ ਤੱਕ ਟਿਕਦਾ ਹੈ, ਹੱਲ ਨਹੀਂ ਹੈ। ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਮੁੜ ਚਾਲੂ ਕਰੋ, VPN ਦੁਬਾਰਾ ਜੋੜੋ, ਅਤੇ ping ਜਾਂ ਛੋਟੀ HTTP ਬੇਨਤੀ ਵਰਗੇ ਬਦਲ ਦੀ ਥਾਂ ਮੂਲ Git ਕਿਰਿਆ ਦੁਹਰਾਓ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਵੇਂ ਸੈਸ਼ਨ ਵਿੱਚ ਇੰਟਰਫੇਸ ਲੋੜੀਂਦਾ ਮੁੱਲ ਢੋਂਦਾ ਹੈ।

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

ਨੋਟ ਕੀਤਾ ਮੂਲ ਮੁੱਲ ਬਦਲਾਅ ਦੇ ਕੋਲ ਰੱਖੋ ਤਾਂ ਜੋ ਪ੍ਰਯੋਗ ਸਾਫ਼-ਸੁਥਰਾ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕੇ, ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜਾ ਪਤਾ ਪਰਿਵਾਰ ਜਾਂਚਿਆ ਗਿਆ, ਕਿਉਂਕਿ IPv4 ਨਤੀਜਾ ਉਸੇ ਹੋਸਟ ਦੇ IPv6 ਕਨੈਕਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। WSL ਨੈੱਟਵਰਕਿੰਗ ਦਸਤਾਵੇਜ਼ ਉਹ ਮੋਡ ਦੱਸਦੇ ਹਨ ਜੋ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਹੱਲ ਕਿਹੋ ਜਿਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; MTU ਸੰਖਿਆ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸਥਾਨਕ ਮਾਪ ਹੈ, ਸਿਫ਼ਾਰਸ਼ ਨਹੀਂ।

ਸੰਬੰਧਿਤ ਲੇਖ