AES-256-GCM ਨਹੀਂ ਮਿਲਿਆ: ਕਲਾਇੰਟ ਦੀ ਸਮਰੱਥਾ ਜਾਂ ਗੱਲਬਾਤ?

ਹੋਰ ਕਿਤੇ ਚੱਲਣ ਵਾਲੀ OpenVPN ਪਰੋਫਾਈਲ ਦੱਸਦੀ ਹੈ ਕਿ AES-256-GCM ਨਹੀਂ ਮਿਲਿਆ, ਜਾਂ ਸਾਥੀਆਂ ਕੋਲ ਕੋਈ ਸਾਂਝਾ ਸਾਈਫਰ ਨਹੀਂ, ਅਤੇ ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਪਰੋਫਾਈਲ ਸੋਧਣ ਦੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਦੋ ਸੁਨੇਹੇ ਵੱਖਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਦੱਸਦੇ ਹਨ। ਇੱਕ ਕਹਿੰਦਾ ਹੈ ਕਿ ਸਥਾਨਕ ਪ੍ਰੋਗਰਾਮ ਕੋਲ ਅਜਿਹਾ ਐਲਗੋਰਿਦਮ ਨਹੀਂ; ਦੂਜਾ ਕਹਿੰਦਾ ਹੈ ਕਿ ਦੋਵੇਂ ਪਾਸੇ ਐਲਗੋਰਿਦਮ ਹਨ ਪਰ ਸਾਂਝੀ ਚੋਣ ਨਹੀਂ। ਕਿਹੜੀ ਹੈ ਇਹ ਜਾਣਨ ਤੱਕ ਪਰੋਫਾਈਲ ਸੋਧ ਕੋਈ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦੀ।

ਗਲਤੀ ਦਾ ਸਹੀ ਪਾਠ ਅਤੇ ਉਹ ਪ੍ਰੋਗਰਾਮ ਪੜ੍ਹੋ ਜਿਸਨੇ ਇਹ ਪੈਦਾ ਕੀਤਾ।

ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਗਲਤੀ ਹੈ

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

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

ਸਥਾਨਕ ਸਮਰੱਥਾ ਦੀ ਘਾਟ

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

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

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

OpenVPN 3 ਆਧਾਰਿਤ ਕਲਾਇੰਟਾਂ ਵਿੱਚ ਇੰਜਣ ਅਤੇ ਸਵੀਕਾਰਯੋਗ ਨਿਰਦੇਸ਼ ਭਾਈਚਾਰੇ ਦੀ 2.x ਲਾਈਨ ਤੋਂ ਵੱਖਰੇ ਹਨ, ਇਸ ਲਈ ਉਹੀ ਪਰੋਫਾਈਲ ਪਾਠ ਸਾਈਫਰ ਸੂਚੀ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਾ ਹੋਣ ਵਾਲੇ ਕਾਰਨਾਂ ਕਰਕੇ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।

ਗੱਲਬਾਤ ਦੀ ਘਾਟ

ਜਦੋਂ ਦੋਵੇਂ ਸਾਥੀ ਐਲਗੋਰਿਦਮ ਸੂਚੀਬੱਧ ਕਰਦੇ ਹਨ, ਬਾਕੀ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਪਾਸਾ ਕਿਹੜੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ। ਭਾਈਚਾਰਕ OpenVPN ਨੇ ਗੱਲਬਾਤ ਨਿਰਦੇਸ਼ ਦਾ ਨਾਮ ਬਦਲਿਆ: 2.4 ਵਿੱਚ ncp-ciphers 2.5 ਵਿੱਚ data-ciphers ਬਣਿਆ, ਅਤੇ 2.6 ਵਿੱਚ ਪੁਰਾਣੀ cipher ਲਾਈਨ ਮੁੱਖ ਤੌਰ ਉੱਤੇ ਅਨੁਕੂਲਤਾ ਅਤੇ ਫਾਲਬੈਕ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ, ਤੈਅ ਕੀਤੇ ਸਮੂਹ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਨਹੀਂ।

ਇਸ ਲਈ ਸਿਰਫ਼ ਪੁਰਾਣੀ cipher ਲਾਈਨ ਬਦਲਣ ਨਾਲ ਗੱਲਬਾਤ ਦੀ ਸੂਚੀ ਅਛੂਤ ਰਹਿ ਸਕਦੀ ਹੈ। ਪੁਰਾਣੀ ਲਾਈਨ ਫਾਲਬੈਕ ਲਈ ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਅਤੇ ਉਹ ਵੱਖਰਾ ਕੰਮ ਹੈ। ਦੋਵੇਂ ਮਿਲਾਉਣ ਨਾਲ ਅਜਿਹੀਆਂ ਸੋਧਾਂ ਬਣਦੀਆਂ ਹਨ ਜੋ ਦਿਸਦਾ ਕੁਝ ਨਹੀਂ ਬਦਲਦੀਆਂ।

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

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

ਅਨੁਕੂਲਤਾ ਸਪਸ਼ਟ ਰੱਖੋ

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

ਦੋ ਸ਼ਰਤਾਂ ਨਤੀਜਾ ਤੈਅ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਗਲਤੀ ਸਥਾਨਕ ਹੈ ਤਾਂ ਬਿਲਡ ਬਦਲੋ। ਜੇ ਗਲਤੀ ਗੱਲਬਾਤ ਦੀ ਹੈ ਤਾਂ ਦੋਵੇਂ ਸਿਰਿਆਂ ਉੱਤੇ ਸੂਚੀਆਂ ਮਿਲਾਓ ਅਤੇ ਲਿਖੋ ਕਿ ਕਿਹੜੇ ਸੰਸਕਰਣ ਸਮਰਥਿਤ ਹਨ।

ਫਿਰ ਸੰਸਕਰਣ ਅਤੇ ਸਮਰੱਥਾ ਦਾ ਆਉਟਪੁੱਟ ਨੱਥੀ ਕਰਕੇ ਸਹੀ ਗਲਤੀ ਦੀ ਰਿਪੋਰਟ ਕਰੋ। ਇਹ ਜੋੜੀ ਗੈਰਹਾਜ਼ਰ ਐਲਗੋਰਿਦਮ ਨੂੰ ਮਤਭੇਦ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ, ਅਤੇ ਅਗਲੇ ਅਨੁਮਾਨਿਤ ਸੋਧ ਦੌਰ ਨੂੰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਦੀ ਹੈ।