Windows ਉੱਤੇ OpenVPN 3 ਅਤੇ Connect ਵਿੱਚ cryptoapicert ਕਿਉਂ ਫੇਲ ਹੁੰਦਾ ਹੈ

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

ਉਸ ਰਿਪੋਰਟ ਵਿੱਚ ਤਿੰਨ ਪਰਤਾਂ ਰਲਾ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: Community ਕਲਾਇੰਟ, ਮੁੱਖ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਕਿਸੇ ਵੱਲੋਂ ਸਥਾਪਿਤ ਕੀਤਾ ਫਰੰਟਐਂਡ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨੇ ਹੀ ਕਦੇ ਇਹ ਨਿਰਦੇਸ਼ ਸਮਝਿਆ।

ਇਹ ਚੋਣ ਜਿੱਥੇ ਮੌਜੂਦ ਹੈ ਉੱਥੇ ਇਸਦਾ ਕੀ ਅਰਥ ਹੈ

Windows ਉੱਤੇ Community OpenVPN 2 ਕਲਾਇੰਟ ਵਿੱਚ, cryptoapicert ਉਸ ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਫਾਈਲ ਵਿੱਚ ਨਹੀਂ, Windows ਸਰਟੀਫਿਕੇਟ ਸਟੋਰ ਵਿੱਚ ਲੱਭਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ Windows-ਖਾਸ ਸੁਵਿਧਾ ਹੈ, ਅਤੇ ਇਹ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਸ ਕਲਾਇੰਟ ਨੂੰ ਸਟੋਰ ਸੂਚੀਬੱਧ ਕਰਨਾ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਮਿਲੀ ਕੁੰਜੀ ਆਪਣੇ TLS ਸਟੈਕ ਨੂੰ ਦੇਣਾ ਆਉਂਦਾ ਹੈ। ਇਸ ਲਈ ਨਿਰਦੇਸ਼ ਉਸ ਕਲਾਇੰਟ ਦੀ ਸੰਰਚਨਾ ਭਾਸ਼ਾ ਦਾ ਹਿੱਸਾ ਹੈ, OpenVPN ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਗੁਣ ਨਹੀਂ। ਸੰਚਾਰ ਫਾਰਮੈਟ ਵਿੱਚ ਇਸਨੂੰ ਢੋਣ ਵਾਲਾ ਕੁਝ ਨਹੀਂ।

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

ਇਸਦੀ ਥਾਂ ਮੁੱਖ ਲਾਇਬ੍ਰੇਰੀ ਕੀ ਦਿੰਦੀ ਹੈ

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

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

ਇਸਦੀ ਥਾਂ Windows ਫਰੰਟਐਂਡ ਕੀ ਕਰਦਾ ਹੈ

OpenVPN Connect ਵੱਖਰਾ ਰਾਹ ਲੈਂਦਾ ਹੈ: ਆਪਰੇਟਰ PKCS#12 ਫਾਈਲ ਆਯਾਤ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਇਸਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ, ਉਸਨੂੰ ਇਸ ਮਕਸਦ ਲਈ ਬਣਾਏ OpenVPN Certificate Store ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਫਿਰ ਬਾਹਰੀ ਸਰਟੀਫਿਕੇਟ ਪਰੋਫਾਈਲ ਨੂੰ ਸੌਂਪਦਾ ਹੈ। ਇਹ ਜਾਣਬੁੱਝ ਕੇ ਕੀਤਾ ਆਯਾਤ ਕਦਮ ਹੈ, ਨਿੱਜੀ ਸਟੋਰ ਵਿੱਚ ਜੋ ਹੈ ਉਸਦੀ ਆਪਣੇ-ਆਪ ਖੋਜ ਨਹੀਂ। ਇਹ ਫਰਕ ਤਦ ਅਹਿਮ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਹੋਰ ਮਕਸਦ ਲਈ ਸਥਾਪਿਤ ਸਰਟੀਫਿਕੇਟ ਸਿਰਫ਼ ਕਲਾਇੰਟ ਦੀ ਸੂਚੀ ਵਿੱਚ ਦਿਸ ਜਾਵੇਗਾ।

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

ਕੁੰਜੀ ਦੀ ਨੀਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਰਾਹ ਚੁਣੋ

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

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

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