ਤੁਸੀਂ client-connect ਸਕ੍ਰਿਪਟ ਜੋੜਦੇ ਹੋ ਜੋ ਹਰ ਉਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ ਜਿੱਥੇ common_name username ਤੋਂ ਵੱਖਰਾ ਹੈ, ਅਤੇ ਇਹ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਖਾਤੇ ਵਿਚਕਾਰ ਬੰਧਨ ਵਰਗਾ ਦਿਸਦਾ ਹੈ। username-as-common-name ਚਲ ਰਹੇ ਸਰਵਰ 'ਤੇ ਸਕ੍ਰਿਪਟ ਚੱਲਣ ਤੱਕ ਉਹ ਤੁਲਨਾ ਆਪਣਾ ਅਰਥ ਗੁਆ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ। ਦੋਵੇਂ ਮੁੱਲ ਇੱਕੋ ਸਟ੍ਰਿੰਗ ਹਨ, ਇਸ ਲਈ ਜਾਂਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਿਸੇ ਹੋਰ ਨੂੰ ਜਾਰੀ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਲਈ ਵੀ ਪਾਸ ਹੁੰਦੀ ਹੈ।

ਜਾਂਚ ਇਸ ਲਈ ਗਲਤ ਨਹੀਂ ਕਿ ਸਕ੍ਰਿਪਟ ਮਾੜੀ ਲਿਖੀ ਗਈ ਹੈ। ਇਹ ਇਸ ਲਈ ਗਲਤ ਹੈ ਕਿ ਜੋ ਮੁੱਲ ਇਹ ਪੜ੍ਹਦੀ ਹੈ ਉਹ ਉਸੇ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਪਹਿਲਾਂ ਬਦਲਿਆ ਗਿਆ ਸੀ।

ਇਹ ਤੁਲਨਾ ਕੀ ਸਾਬਤ ਕਰਦੀ ਦਿਸਦੀ ਹੈ

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

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

username-as-common-name ਨਾਮ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ

username-as-common-name ਚਾਲੂ ਹੋਣ 'ਤੇ, OpenVPN ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਤਸਦੀਕ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸਰਟੀਫਿਕੇਟ ਦੇ ਆਮ ਨਾਮ ਦੀ ਥਾਂ ਪ੍ਰਮਾਣਿਤ ਵਰਤੋਂਕਾਰ ਨਾਮ ਰੱਖਦਾ ਹੈ। ਉਸ ਜਾਂਚ ਦੌਰਾਨ ਚੱਲਣ ਵਾਲਾ ਤਸਦੀਕ ਹੁੱਕ ਅਜੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਦਾ ਆਮ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਬਦਲੀ ਅਜੇ ਨਹੀਂ ਹੋਈ। ਉਸ ਤੋਂ ਬਾਅਦ ਦਾ ਸਭ ਕੁਝ, client-connect ਸਮੇਤ, ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੇਖਦਾ ਹੈ। ਇਸ ਲਈ ਬਾਅਦ ਵਾਲਾ ਕਾਲਬੈਕ ਇੱਕੋ ਪਛਾਣ ਦੋ ਵਾਰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਉਸ ਦੀ ਤੁਲਨਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।

StageWhat common_name holds
Username and password verification hookThe certificate common name, for example bob-device
After the replacementThe authenticated account, alice
client-connect callbackThe account again, alice

ਇੱਕ ਉਦਾਹਰਨ ਕਨੈਕਸ਼ਨ ਦੇਖੋ: bob-device ਲਈ ਜਾਰੀ ਸਰਟੀਫਿਕੇਟ, alice ਵਜੋਂ ਸਫਲ ਡਾਇਰੈਕਟਰੀ ਲੌਗਇਨ, ਅਤੇ ਵਿਕਲਪ ਚਾਲੂ। ਤਸਦੀਕ ਪੜਾਅ ਅਜੇ ਵੀ ਦੋ ਵੱਖਰੀਆਂ ਸਟ੍ਰਿੰਗਾਂ ਦੇਖ ਸਕਦਾ ਹੈ। ਕਨੈਕਸ਼ਨ ਪੜਾਅ alice ਅਤੇ alice ਦੇਖਦਾ ਹੈ।

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

ਬੰਧਨ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਦੋਵੇਂ ਪਛਾਣਾਂ ਅਜੇ ਵੀ ਮੌਜੂਦ ਹਨ

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

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

ਯਾਦ ਰੱਖੋ ਕਿ ਵਿਕਲਪ ਇਹ ਵੀ ਬਦਲਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਕਨਫਿਗਰੇਸ਼ਨ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ client-config-dir ਆਮ ਨਾਮ ਦੁਆਰਾ ਨਿਰਧਾਰਿਤ ਹੁੰਦਾ ਹੈ।

ਦੋ ਵੈਧ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਨਾਲ ਜੋੜੀ ਦੀ ਜਾਂਚ ਕਰੋ

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

ਸਰਟੀਫਿਕੇਟ ਗੁੰਮ ਅਤੇ ਅਵੈਧ ਸਰਟੀਫਿਕੇਟ ਵਾਲੇ ਰਾਹ ਵੀ ਜਾਂਚੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰਵਰ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਸੈਟਿੰਗਾਂ ਲਈ ਕਿਹੜੀ ਪਛਾਣ ਵਰਤਦਾ ਹੈ। ਜੇ ਤੁਲਨਾ ਕੰਮ ਕਰਾਉਣ ਦਾ ਇੱਕੋ ਤਰੀਕਾ username-as-common-name ਬੰਦ ਕਰਨਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਉਸ ਬਦਲਾਅ ਦੀ ਕੀਮਤ ਦੇਖੋ, ਕਿਉਂਕਿ ਇਹ ਹਰ ਕਲਾਇੰਟ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਖੋਜ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਦੇ ਨਾਮ 'ਤੇ ਵਾਪਸ ਲੈ ਜਾਂਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ