«ਕੋਈ ਸਾਂਝਾ ਸਾਈਫਰ ਨਹੀਂ» ਗਲਤੀ ਇੱਕੋ ਸੈਟਿੰਗ ਬਦਲਣ ਵਰਗੀ ਲੱਗਦੀ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਜੋ ਸੈਟਿੰਗ ਬਦਲਦੇ ਹਨ ਉਹੀ ਗਲਤ ਹੈ। OpenVPN TLS ਹੈਂਡਸ਼ੇਕ ਕਰਨ ਵਾਲੇ ਕੰਟਰੋਲ ਚੈਨਲ ਅਤੇ ਟਨਲ ਅੰਦਰ ਪੈਕਟ ਲਿਜਾਣ ਵਾਲੇ ਡੇਟਾ ਚੈਨਲ ਲਈ ਵੱਖਰੀਆਂ ਨੀਤੀਆਂ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਗਲਤੀ ਪਹਿਲੇ ਦਾ ਨਾਂ ਲੈਂਦੀ ਹੈ ਜਦਕਿ ਲੋਕ ਦੂਜੇ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੇ ਹਨ। ਹਰ ਧਿਰ ਕੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦੀ ਹੈ ਦੀ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਤੁਲਨਾ ਕਰਨਾ ਅੰਦਾਜ਼ੇ ਨੂੰ ਦੋ ਜਾਂ ਤਿੰਨ ਫੈਸਲਿਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਸੰਸਕਰਣ, ਫਿਰ ਸਿਊਟ ਸੂਚੀ, ਫਿਰ ਪ੍ਰਮਾਣ ਪੱਤਰ।

ਇਹ ਕ੍ਰਮ ਗਲਤ ਹੋਵੇ ਤਾਂ ਕਦੇ ਨਾ ਵੇਖੀ ਗਈ ਸੂਚੀ ਵਿੱਚ AES ਨਾਂ ਜੋੜਨ ਵਿੱਚ ਇੱਕ ਘੰਟਾ ਬਰਬਾਦ ਹੋ ਸਕਦਾ ਹੈ।

ਦੋ ਸਾਈਫਰ ਸੂਚੀਆਂ, ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਤੋੜਦੀ ਹੈ ਸਿਰਫ਼ ਇੱਕ

ਕੰਟਰੋਲ ਚੈਨਲ TLS ਸੈਸ਼ਨ ਉੱਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਨੀਤੀ ਇਸ ਨਾਲ ਲਿਖੀ ਜਾਂਦੀ ਹੈ: tls-cipher TLS 1.2 ਲਈ ਅਤੇ tls-ciphersuites TLS 1.3 ਲਈ। ਡੇਟਾ ਚੈਨਲ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਇਸ ਨਾਲ ਸੰਰਚਿਤ ਹੁੰਦਾ ਹੈ: data-ciphers, ਜਿੱਥੇ ਅਸੰਗਤੀ ਐਸਾ ਕਨੈਕਸ਼ਨ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਸਥਾਪਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਟ੍ਰੈਫਿਕ ਲੰਘਾ ਨਹੀਂ ਸਕਦਾ। ਦੋਵੇਂ ਸਾਈਫਰ ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਇਨ੍ਹਾਂ ਨੂੰ ਰਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਕਦੇ ਪੂਰਾ ਨਾ ਹੋਣ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਕੰਟਰੋਲ ਚੈਨਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਸਥਾਪਿਤ ਟਨਲ ਪੈਕਟ ਸੁੱਟੇ ਤਾਂ ਉਹ ਡੇਟਾ ਚੈਨਲ ਵੱਲ।

ਪਹਿਲੀ ਲਾਈਨ ਦੀ ਥਾਂ ਪੂਰਾ ਸੁਨੇਹਾ ਪੜ੍ਹੋ। ਸੰਸਕਰਣ ਅਸੰਗਤੀ, ਗੁੰਮ ਸਿਊਟ, ਧਿਰ ਵੱਲੋਂ ਨਾਮਨਜ਼ੂਰ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ ਦਸਤਖ਼ਤ ਅਲਗੋਰਿਦਮ, ਅਤੇ ਹੋਸਟਨਾਮ ਜਾਂਚ ਦੀ ਅਸਫਲਤਾ—ਸਾਰੇ TLS ਗਲਤੀ ਵਿੱਚ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਤੁਹਾਡੀ ਸਿਊਟ ਸੂਚੀ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਇਹ ਸ਼੍ਰੇਣੀਆਂ ਵੱਖ ਰੱਖਣਾ ਹੀ ਨਿਦਾਨ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹੈ।

ਸਿਊਟ ਦੀ ਤੁਲਨਾ ਤੋਂ ਪਹਿਲਾਂ ਸੰਸਕਰਣਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

TLS 1.2 ਤੱਕ ਸੀਮਿਤ ਧਿਰ ਅਤੇ 1.3 ਲਾਜ਼ਮੀ ਮੰਨਣ ਵਾਲੀ ਧਿਰ ਕੋਈ ਸੰਸਕਰਣ ਸਾਂਝਾ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਕੋਈ ਸਾਈਫਰ ਸਟਰਿੰਗ ਇਸ ਨੂੰ ਨਹੀਂ ਜੋੜਦੀ। ਦੋਵੇਂ ਪਾਸੇ tls-version-min ਅਤੇ tls-version-max ਦਰਜ ਕਰੋ, ਜਾਂ ਵਰਤੇ ਜਾ ਰਹੇ ਬਿਲਡਾਂ ਦੇ ਡਿਫ਼ਾਲਟ, ਕਿਉਂਕਿ ਕਿਸੇ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਦੀ OpenSSL ਨੀਤੀ ਘੱਟੋ-ਘੱਟ ਸੀਮਾ ਵਧਾ ਸਕਦੀ ਹੈ ਅਤੇ ਕੋਈ OpenVPN ਚੋਣ ਇਹ ਨਹੀਂ ਕਹੇਗੀ। ਜੇ ਇੱਕ ਧਿਰ ਡਿਵਾਈਸ ਜਾਂ ਤੀਜੀ ਧਿਰ ਦਾ ਕਲਾਇੰਟ ਹੈ, ਤਾਂ ਉਸ ਦੀ ਵਿੰਡੋ ਉਹੀ ਹੈ ਜਿਸ ਦੀ ਉਸ ਦਾ ਫਰਮਵੇਅਰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ। ਵਿੰਡੋਆਂ ਓਵਰਲੈਪ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਸਿਊਟ ਤੁਲਨਾ ਦਾ ਕੋਈ ਅਰਥ ਹੈ।

ਉਹ ਰਿਕਾਰਡ ਅਸਲ ਬਾਇਨਰੀਆਂ ਦਾ ਨਾਂ ਵੀ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਉੱਤੇ ਕਮਾਂਡਲਾਈਨ openvpn ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਉਹੀ ਕਲਾਇੰਟ ਹੋਵੇ ਜੋ ਆਯਾਤ ਕੀਤੀ ਪਰੋਫ਼ਾਈਲ ਸੰਭਾਲਦਾ ਹੈ।

TLS 1.2 ਅਤੇ TLS 1.3 ਦੀਆਂ ਸੂਚੀਆਂ ਨਹੀਂ ਰਲਦੀਆਂ

TLS 1.2 ਸਿਊਟਾਂ ਦੇ ਨਾਂ ਇਵੇਂ ਦਿਸਦੇ ਹਨ: ECDHE-RSA-AES256-GCM-SHA384 ਅਤੇ ਉਹ tls-cipher ਵਿੱਚ ਜਾਂਦੇ ਹਨ, ਜੋ OpenSSL ਸਾਈਫਰ ਸਟਰਿੰਗ ਲੈਂਦਾ ਹੈ। TLS 1.3 ਸਿਊਟਾਂ ਦੇ ਨਾਂ ਇਵੇਂ ਹਨ: TLS_AES_256_GCM_SHA384 ਅਤੇ ਉਹ tls-ciphersuites ਵਿੱਚ ਜਾਂਦੇ ਹਨ; 1.2 ਸਟਰਿੰਗ ਵਿੱਚ ਇੱਕ ਜੋੜਨ ਨਾਲ 1.3 ਸੂਚੀ ਸੰਰਚਿਤ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਪਾਰਸਰ ਕਦੇ ਨਾ ਮਿਲਾਉਂਦੇ ਹੋਏ ਵੀ ਲਿਖਤ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਸੰਸਕਰਣ ਲਈ ਸਹੀ ਫਿਲਟਰ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਲਿਖੋ ਕਿ ਕਿਹੜੀ ਸੂਚੀ ਕਿਹੜੇ ਸੰਸਕਰਣ ਲਈ ਹੈ।

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

ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਗੱਲਬਾਤ ਸਿੱਧ ਕਰੋ

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

ਜੇ ਕੋਈ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸਾਂਝੀ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ, ਤਾਂ ਜਵਾਬ ਅੱਪਗ੍ਰੇਡ ਜਾਂ ਸਥਾਨਾਂਤਰਨ ਯੋਜਨਾ ਹੈ, ਕਮਜ਼ੋਰ ਕੀਤੀ ਨੀਤੀ ਨਹੀਂ। tls-version-min ਘਟਾਉਣਾ, ਜਾਂਚ ਬੰਦ ਕਰਨਾ ਜਾਂ ਸਾਰੀਆਂ ਪੁਰਾਣੀਆਂ ਸਿਊਟਾਂ ਸਮਰੱਥ ਕਰਨਾ ਉਸ ਸੁਰੱਖਿਆ ਲੋੜ ਨੂੰ ਪੂਰਾ ਕੀਤੇ ਬਿਨਾਂ ਨਾਮਨਜ਼ੂਰੀ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੇ ਇਸ ਨੂੰ ਪੈਦਾ ਕੀਤਾ।

ਬਦਲਾਅ ਟਿਕਟ ਵਿੱਚ ਗੱਲਬਾਤ ਵਾਲਾ ਸੰਸਕਰਣ, ਸਿਊਟ ਅਤੇ ਡੇਟਾ ਸਾਈਫਰ ਦਰਜ ਕਰੋ। ਅਗਲੀ ਵਾਰ TLS ਗਲਤੀ ਮਿਲਣ ਵਾਲਾ ਵਿਅਕਤੀ ਫੋਰਮ ਪੋਸਟ ਵਿੱਚ ਮਿਲੀ ਸਾਈਫਰ ਸਟਰਿੰਗ ਤੋਂ ਨਹੀਂ, ਉਸੇ ਰਿਕਾਰਡ ਤੋਂ ਸ਼ੁਰੂ ਕਰੇਗਾ।

ਸੰਬੰਧਿਤ ਲੇਖ