OpenSSL 3 ਤੋਂ ਬਾਅਦ OpenVPN ਕੁੰਜੀ ਪ੍ਰੋਂਪਟ: ਪ੍ਰਦਾਤਾ ਦੀ ਜਾਂਚ ਕਰੋ

ਕਿਸੇ ਨੇ ਵੀ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਨਹੀਂ ਛੋਹਿਆ, ਫਿਰ ਵੀ ਉਹੀ ਕਲਾਇੰਟ ਹੁਣ ਹਰ ਵਾਰ ਸ਼ੁਰੂ ਹੋਣ ’ਤੇ ਨਿੱਜੀ ਕੁੰਜੀ ਲਈ ਪਾਸਫਰੇਜ਼ ਮੰਗਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਬਦਲਾਅ ਕਿਸੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਅਪਗ੍ਰੇਡ ਤੋਂ ਕੁਝ ਦਿਨਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਅਪਗ੍ਰੇਡ ਹੀ ਸੰਭਾਵੀ ਕਾਰਨ ਹੈ: OpenSSL 3 ਨੇ ਆਪਣਾ ਐਲਗੋਰਿਦਮ ਸਹਿਯੋਗ ਮੁੜ ਸੰਗਠਿਤ ਕੀਤਾ, ਅਤੇ ਪੁਰਾਣੀ ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਕੁੰਜੀ ਆਸਾਨੀ ਨਾਲ ਪੜ੍ਹਦੀ ਸੀ, ਉਹ ਇੱਕ ਵੀ ਬਾਈਟ ਬਦਲੇ ਬਿਨਾਂ ਅਪੜ੍ਹਨਯੋਗ ਹੋ ਸਕਦੀ ਹੈ। ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਪ੍ਰੋਂਪਟ ਵੇਖਣ ’ਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਦੋ ਇੱਕੋ ਜਿਹੀਆਂ ਲੱਗਦੀਆਂ ਹਨ।

ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੁੰਜੀ ਐਨਕ੍ਰਿਪਟ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਦੂਜਾ ਇਹ ਕਿ ਇਹ ਬਿਲਡ ਇਸਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਦੋਵੇਂ ਜਵਾਬ ਜਾਣਨ ਤੋਂ ਬਾਅਦ ਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਣ ਦਾ ਅਰਥ ਹੈ।

ਜਾਂਚੋ ਕਿ ਕੁੰਜੀ ਐਨਕ੍ਰਿਪਟ ਹੈ ਜਾਂ ਨਹੀਂ

ਫਾਈਲ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਪੜ੍ਹੋ ਅਤੇ ਫਿਰ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਇਸਨੂੰ ਪਾਰਸ ਕਰਨ ਦਿਓ, ਕਿਉਂਕਿ ਫਾਈਲ ਦਾ ਨਾਮ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਲੇਬਲ ਵਾਲਾ PEM ਬਲਾਕ ENCRYPTED PRIVATE KEY ਐਨਕ੍ਰਿਪਟਿਡ PKCS#8 ਹੈ, ਅਤੇ ਪੁਰਾਣਾ RSA PRIVATE KEY ਬਲਾਕ ਜਿਸ ਵਿੱਚ Proc-Type: 4,ENCRYPTED ਹੈ ਉਹ ਰਵਾਇਤੀ ਰੂਪ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਪਾਸਫਰੇਜ਼ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਐਨਕ੍ਰਿਪਟ ਨਾ ਕੀਤਾ PRIVATE KEY ਬਲਾਕ ਤਾਂ ਇਹ ਬਿਲਕੁਲ ਨਹੀਂ ਮੰਗਣਾ ਚਾਹੀਦਾ। ਪਾਰਸਿੰਗ ਉਸੇ ਖਾਤੇ ਨਾਲ ਚਲਾਓ ਜੋ ਫਾਈਲ ਦਾ ਮਾਲਕ ਹੈ, ਕਿਉਂਕਿ ਇਜਾਜ਼ਤ ਦੀ ਸਮੱਸਿਆ ਵੱਖਰੀ ਅਤੇ ਕਾਫ਼ੀ ਘੱਟ ਦਿਲਚਸਪ ਗਲਤੀ ਦਿੰਦੀ ਹੈ।

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

ਜਾਂਚੋ ਕਿ ਇਹ ਬਿਲਡ ਇਸਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ

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

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

ਉਪਲਬਧ ਸਭ ਤੋਂ ਸੰਕੀਰਣ ਉਪਾਅ ਦੀ ਜਾਂਚ ਕਰੋ

ਸਿਸਟਮ-ਵਿਆਪੀ ਬਦਲਾਅ ਦੀ ਬਜਾਏ ਕਲਾਇੰਟ ਤੱਕ ਸੀਮਿਤ ਬਦਲਾਅ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਕੁਝ 2.6 ਬਿਲਡ ਉਹ ਪ੍ਰੋਫਾਈਲ ਵਿਕਲਪ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਜੋ ਉਸ ਡੈਮਨ ਪ੍ਰਕਿਰਿਆ ਲਈ ਦੋਵੇਂ ਪ੍ਰਦਾਤਾ ਲੋਡ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਉਸ ’ਤੇ ਨਿਰਭਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਸਹੀ ਸੰਸਕਰਣ ਦੇ ਮੈਨੂਅਲ ਵਿੱਚ ਹਦਾਇਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ; ਇਸ ਦੀ ਬਜਾਏ ਸਿਸਟਮ ਦੀ openssl.cnf ਸੋਧਣ ਨਾਲ ਹੋਸਟ ’ਤੇ ਹਰ OpenSSL ਪ੍ਰੋਗਰਾਮ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ। ਸੰਕੀਰਣ ਸੈਟਿੰਗ ਕੁੰਜੀ ਮੁੜ ਐਨਕੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਕਰਨਾ ਵੀ ਬਹੁਤ ਸੌਖਾ ਹੈ।

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

ਸੇਵਾ ਦਾ ਸੰਦਰਭ ਜਾਂਚੋ, ਫਿਰ ਮੁੜ ਐਨਕੋਡ ਕਰੋ

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

ਫਿਰ ਉਸ ਯੂਨਿਟ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਅਸਲ ਵਿੱਚ ਕਲਾਇੰਟ ਚਲਾਉਂਦੀ ਹੈ। ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਵਿੱਚ ਪੜ੍ਹਨਯੋਗ ਕੁੰਜੀ ਕਿਸੇ ਹੋਰ ਖਾਤੇ ਹੇਠ ਜਾਂ ਕਠੋਰ ਕੀਤੀ ਗਈ ਹੋਮ ਡਾਇਰੈਕਟਰੀ ਸੈਟਿੰਗ ਨਾਲ ਚੱਲ ਰਹੀ ਸੇਵਾ ਲਈ ਅਪੜ੍ਹਨਯੋਗ ਹੋ ਸਕਦੀ ਹੈ।

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

ਪ੍ਰੋਂਪਟ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਕਾਰਨਾਂ ਵਾਲਾ ਲੱਛਣ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਗੁੰਮ ਪਾਸਫਰੇਜ਼ ਹੈ।