SSH2_MSG_KEX_ECDH_REPLY 'ਤੇ SSH ਅਟਕਦਾ ਹੈ: ਹਮੇਸ਼ਾ MTU ਨਹੀਂ

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

ਜਵਾਬ ਅਸਲ ਵਿੱਚ ਉਮੀਦ ਸੀ ਜਾਂ ਨਹੀਂ, ਇਹ ਵੇਖਣ ਲਈ ਟਰੇਸ ਪੜ੍ਹੋ

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

ਆਖਰੀ ਮਾਮਲੇ ਵਿੱਚ, ਕਲਾਇੰਟ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਵਰ ਦਾ ਪ੍ਰਮਾਣੀਕਰਨ ਲਾਗ ਪੜ੍ਹੋ। ਸਰਵਰ ਨੇ ਕਦੇ ਨਾ ਭੇਜਿਆ ਫੈਸਲਾ ਕਲਾਇੰਟ ਵੇਖ ਨਹੀਂ ਸਕਦਾ।

ਛੋਟਾ ਜਵਾਬ ਵੀ ਕਿਉਂ ਬਹੁਤ ਵੱਡਾ ਹੋ ਸਕਦਾ ਹੈ

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

ਆਕਾਰ ਮੰਨਣ ਦੀ ਬਜਾਏ ਨਿਰਧਾਰਤ ਕਰੋ। ip link show tun0 ਨਾਲ ਟਨਲ ਦਾ MTU ਪੜ੍ਹੋ, ਫਿਰ ਅਜਿਹੀਆਂ ਪ੍ਰੋਬ ਭੇਜੋ ਜੋ ਟੁਕੜੇ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ: ping -4 -M do -s 1352 host, ਛੋਟੇ ਪੇਲੋਡ ਨਾਲ ਦੁਹਰਾਓ। ਕਿਸੇ ਖਾਸ ਆਕਾਰ 'ਤੇ ਅਸਫਲਤਾ ਤੋਂ ਸਫਲਤਾ ਵਿੱਚ ਬਦਲਾਅ ਸਬੂਤ ਹੈ; ਇਕਸਾਰ ਅਸਫਲਤਾ ਦੱਸਦੀ ਹੈ ਕਿ ICMP ਫਿਲਟਰ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।

ਅਸਥਾਈ ਘਟਾਓ ਸਿਧਾਂਤ ਦੀ ਤੇਜ਼ੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਥਾਈ ਸੰਸਕਰਣ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਜਾਂ ਟਨਲ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਰਾਊਟਰ 'ਤੇ MSS ਕਲੈਂਪ ਵਜੋਂ ਰਹਿੰਦਾ ਹੈ:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਦੀ ਨਕਲ ਕਰਨ ਵਾਲੇ ਦੋ ਕਾਰਨ

ਕਲਾਇੰਟ ਜੋ ਕੁੰਜੀ ਫਾਈਲ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ, ਉਹੀ ਉਡੀਕ ਪੈਦਾ ਕਰਦੀ ਹੈ, ਵਿਸਤ੍ਰਿਤ ਆਉਟਪੁੱਟ ਵਿੱਚ ਵੀ ਚੇਤਾਵਨੀ ਤੋਂ ਬਿਨਾਂ। known_hosts ਦਾ ਇੱਕ ਪੈਟਰਨ ਇਸਨੂੰ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ: ਸਿਰਫ਼ ਇੱਕ ਖਾਤਾ ਪੜ੍ਹ ਸਕਣ ਵਾਲੀ CA ਜਨਤਕ ਕੁੰਜੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ @cert-authority ਐਂਟਰੀ। ਜਿਸ ਖਾਤੇ ਕੋਲ ਫਾਈਲ ਹੈ ਉਹ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਹਰ ਦੂਜਾ ਖਾਤਾ ਅਟਕ ਜਾਂਦਾ ਹੈ। ਜੇ ਅਸਫਲਤਾ ਹੋਸਟ ਦੀ ਬਜਾਏ ਵਰਤੋਂਕਾਰ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਪੈਕਟ ਆਕਾਰਾਂ ਤੋਂ ਪਹਿਲਾਂ ਫਾਈਲ ਮੋਡ ਵੇਖੋ।

ਅੱਪਗ੍ਰੇਡ ਉਹ ਐਲਗੋਰਿਦਮ ਵੀ ਹਟਾ ਸਕਦਾ ਹੈ ਜੋ ਦੋਵੇਂ ਸਿਰੇ ਪਹਿਲਾਂ ਸਾਂਝਾ ਕਰਦੇ ਸਨ। ਸਰਵਰ ਵੱਲੋਂ ਅਜੇ ਵੀ ਦਿੱਤੀ ਜਾਣ ਵਾਲੀ ਇੱਕ ਵਿਧੀ ਨੂੰ ਨਿਦਾਨ ਵਜੋਂ ਪਿੰਨ ਕਰੋ: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host। ਤੁਰੰਤ ਸਫਲ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਰਸਤਾ ਠੀਕ ਹੈ ਅਤੇ ਸੁਧਾਰ ਦੋਵੇਂ ਪਾਸਿਆਂ ਦੀ ਗੱਲਬਾਤ ਨੀਤੀ ਵਿੱਚ ਹੈ।

ਲਿਖਣ ਯੋਗ ਤਿੰਨ ਤੱਥ

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

ਉਹ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਅਜਿਹੀ ਖਰਾਬੀ ਲਈ MTU ਘਟਾਉਣ ਤੋਂ ਵੀ ਰੋਕਦੇ ਹਨ ਜੋ ਕਦੇ ਆਕਾਰ ਬਾਰੇ ਨਹੀਂ ਸੀ।

ਜੇ ਤਸਵੀਰ ਅਜੇ ਵੀ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਸੇ ਟਨਲ 'ਤੇ ਦੂਜੇ ਕਲਾਇੰਟ ਤੋਂ ਪਰਖੋ। ਜੁੜਨ ਵਾਲਾ ਕਲਾਇੰਟ ਖਰਾਬੀ ਨੂੰ ਰਸਤੇ ਤੋਂ ਪਹਿਲੀ ਮਸ਼ੀਨ ਦੀ ਸੰਰਚਨਾ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ।