ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਤੋਂ ਬਿਨਾਂ OpenVPN: ਸਰਵਰ ਨੀਤੀ, ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ
ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਕੁੰਜੀ ਦੀਆਂ ਲਾਈਨਾਂ ਮਿਟਾਉਣ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ ਜੇ ਸਰਵਰ ਅਜੇ ਵੀ ਉਨ੍ਹਾਂ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। ਮੰਗ ਨੂੰ ਸਰਵਰ ਵੱਲ ਲੈ ਜਾਓ ਅਤੇ ਕਲਾਇੰਟ ਦੀਆਂ ਆਪਣੀਆਂ ਸਰਵਰ ਜਾਂਚਾਂ ਰੱਖੋ।
ਤੁਸੀਂ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਕੁੰਜੀ ਦੀਆਂ ਲਾਈਨਾਂ ਮਿਟਾਉਂਦੇ ਹੋ, ਪ੍ਰੋਫਾਈਲ ਸੌਂਪਦੇ ਹੋ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਅਜੇ ਵੀ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਕਦੇ ਵੀ ਉਹ ਚੀਜ਼ ਨਹੀਂ ਸੀ ਜੋ ਉਸ ਮੰਗ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਸੀ। ਸਰਵਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਲਾਜ਼ਮੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਕਲਾਇੰਟ ਪਾਸੇ ਦਾ ਕੋਈ ਸੋਧ ਗੱਲਬਾਤ ਰਾਹੀਂ ਇਸਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਲਈ ਹੱਲ ਸਰਵਰ ਨੀਤੀ ਵਿੱਚ ਬਦਲਾਅ ਹੈ, ਜਾਣਬੁੱਝ ਕੇ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਇਸ 'ਤੇ ਨਿਰਭਰ ਸਭ ਕੁਝ ਉਸੇ ਪੜਾਅ ਵਿੱਚ ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ।
ਪ੍ਰੋਫਾਈਲ ਨੀਤੀ ਨਹੀਂ ਹੈ
Community OpenVPN 2.6 ਲਾਜ਼ਮੀ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਆਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ verify-client-cert ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ require ਹੈ। ਇਸਨੂੰ none 'ਤੇ ਸੈੱਟ ਕਰਨਾ ਹੀ ਸਰਟੀਫਿਕੇਟ ਦੀ ਮੰਗ ਰੋਕਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਉਸ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਪ੍ਰਬੰਧ ਨੂੰ ਸੌਂਪਦਾ ਹੈ ਜੋ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ਚਲਾ ਰਿਹਾ ਹੈ। ਪੁਰਾਣੀਆਂ ਗਾਈਡਾਂ ਉਸੇ ਵਿਚਾਰ ਦੀ ਪੁਰਾਣੀ ਸਪੈਲਿੰਗ client-cert-not-required ਵੱਲ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹ ਨਿਰਦੇਸ਼ ਵਰਤੋਂ ਜੋ ਤੁਹਾਡਾ ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਬਦਲਾਅ ਸਰਵਰ 'ਤੇ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਇਸਨੂੰ ਕਰ ਨਹੀਂ ਸਕਦਾ।
ਹੇਠਾਂ ਦਿੱਤਾ ਟੁਕੜਾ ਸਰਵਰ ਪਾਸੇ ਦਾ ਪੂਰਾ ਬਦਲਾਅ ਹੈ, ਅਤੇ ਇਕੱਲਾ ਇਹ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪ੍ਰਮਾਣਿਕਤਾ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ। verify-client-cert none ਸਰਟੀਫਿਕੇਟ ਦੀ ਮੰਗ ਹਟਾਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ username-as-common-name ਖਾਤੇ ਦੇ ਨਾਮ ਨੂੰ ਉਹ ਪਛਾਣ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਬਾਅਦ ਦੇ ਕਾਲਬੈਕ ਅਤੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਫਾਈਲਾਂ ਦੇਖਦੀਆਂ ਹਨ। ਕੋਈ ਵੀ ਲਾਈਨ ਪਾਸਵਰਡ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦੀ, ਇਸ ਲਈ ਇੱਕ ਸਤਿਆਪਕ ਅਜੇ ਵੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
verify-client-cert none
username-as-common-name
ਉਹ ਸਤਿਆਪਕ auth-user-pass-verify ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਣ ਵਾਲਾ ਪਲੱਗਇਨ ਜਾਂ ਸਕ੍ਰਿਪਟ ਹੈ, ਅਤੇ ਇਹ ਉੱਪਰਲੀਆਂ ਕਿਸੇ ਵੀ ਲਾਈਨ ਦੇ ਅਰਥ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਥਾਂ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕ੍ਰਮ ਉਲਟਣ ਨਾਲ ਤੁਹਾਨੂੰ ਇੱਕ ਵਿੰਡੋ ਮਿਲਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਸਰਵਰ ਕੋਈ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਮੰਗਦਾ ਅਤੇ ਕੋਈ ਖਾਤਾ ਨਹੀਂ ਜਾਂਚਦਾ।
ਸਰਵਰ ਨੂੰ ਅਜੇ ਵੀ ਕੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ
ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਛੱਡਣਾ TLS ਛੱਡਣਾ ਨਹੀਂ ਹੈ। ਸਰਵਰ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਕੁੰਜੀ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ CA ਭਰੋਸਾ ਅਤੇ ਹੋਸਟਨਾਮ ਜਾਂਚਾਂ ਰੱਖਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਇੱਕ ਧੋਖੇਬਾਜ਼ ਨਾਲ ਗੱਲ ਕਰਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ। ਕਲਾਇੰਟ ਕੋਲ ਹੁਣ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਹੈ ਇਸ ਲਈ remote-cert-tls server ਜਾਂ CA ਬੰਡਲ ਹਟਾਉਣਾ ਇੱਕ ਆਮ ਅਤੇ ਗੰਭੀਰ ਗਲਤ ਪੜ੍ਹਤ ਹੈ, ਅਤੇ 2.6 ਹਵਾਲਾ ਸਪਸ਼ਟ ਹੈ ਕਿ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਸੁਤੰਤਰ ਹਨ। ਇੱਕ ਸਰਵਰ ਨੂੰ ਕਲਾਇੰਟ ਸਾਮ੍ਹਣੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦੀ ਹੈ; ਦੂਜੀ ਸਰਵਰ ਸਾਮ੍ਹਣੇ ਕਲਾਇੰਟ ਨੂੰ।
ਪ੍ਰੋਫਾਈਲ tls-auth ਜਾਂ tls-crypt ਬਲਾਕ ਵੀ ਰੱਖ ਸਕਦਾ ਹੈ। ਉਹ ਆਪਣੇ ਵੰਡ ਅਤੇ ਘੁੰਮਣ ਚੱਕਰ ਵਾਲੀ ਸਾਂਝੀ ਨਿਯੰਤਰਣ-ਚੈਨਲ ਕੁੰਜੀ ਹੈ, ਇਸ ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਕੁੰਜੀ ਦੀਆਂ ਲਾਈਨਾਂ ਤੋਂ ਬਿਨਾਂ ਫਾਈਲ ਆਪਣੇ ਆਪ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਪੜ੍ਹ ਨਹੀਂ ਲੈਂਦੇ, ਇਸਨੂੰ ਗੁਪਤ ਸਮਝੋ।
ਕੰਮ ਕਰਨ ਵਾਲੇ ਪ੍ਰੋਫਾਈਲ ਤੋਂ ਕਾਪੀ ਕੀਤੀ ਸਰਟੀਫਿਕੇਟ ਫਾਈਲ ਆਪਣੇ ਆਪ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ; ਮਾਲਕੀ ਦਾ ਮਤਲਬ ਹੈ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਰੱਖਣਾ, ਜੋ ਸਰਟੀਫਿਕੇਟ-ਪ੍ਰਮਾਣਿਤ ਤੈਨਾਤੀ ਜਾਂਚਦੀ ਹੈ। ਸਰਟੀਫਿਕੇਟ ਵਾਲੀ ਫਾਈਲ ਉਹ ਫਾਈਲ ਨਹੀਂ ਹੈ ਜਿਸ ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਕੀਤੀ ਜਾ ਸਕੇ।
ਸਤਿਆਪਕ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ
ਸਰਟੀਫਿਕੇਟ ਦੀ ਮੰਗ ਹਟਾਉਣ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਸਤਿਆਪਕ 'ਤੇ ਟਿਕਦਾ ਹੈ: ਇੱਕ ਪਲੱਗਇਨ, ਜਾਂ auth-user-pass-verify ਦੁਆਰਾ ਚਲਾਈ ਜਾਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ। ਇਸਨੂੰ ਅਵੈਧ ਪ੍ਰਮਾਣ ਪੱਤਰ ਰੱਦ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਅਸਮਰੱਥ ਜਾਂ ਅਯੋਗ ਖਾਤੇ ਰੱਦ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਇਹ ਆਪਣੇ ਬੈਕਐਂਡ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ ਤਾਂ ਬੰਦ ਹੋ ਕੇ ਅਸਫਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। username-as-common-name ਅਕਸਰ ਨਾਲ ਸਮਰੱਥ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਪਛਾਣ ਨੂੰ ਬਦਲਦਾ ਹੈ ਜੋ ਬਾਅਦ ਦੇ ਕਾਲਬੈਕ ਅਤੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਦੇਖਦੀਆਂ ਹਨ। ਇਹ ਪਾਸਵਰਡ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਅਯੋਗ ਖਾਤੇ ਨੂੰ ਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਵੱਖਰੇ ਕੰਮ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਆਪਣੀ ਸੁਖਦ-ਮਾਰਗ ਪਰਖ ਪਾਸ ਕਰਦੀ ਹੈ ਅਤੇ ਆਪਣੀ ਪਹਿਲੀ ਅਸਲ ਘਟਨਾ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦੀ ਹੈ।
ਨਕਾਰਾਤਮਕ ਮਾਮਲਿਆਂ ਨੂੰ ਸਕਾਰਾਤਮਕ ਮਾਮਲੇ ਜਿੰਨੀ ਹੀ ਸਾਵਧਾਨੀ ਨਾਲ ਪਰਖੋ। ਪਾਸਵਰਡ ਸੰਕੇਤ ਦਿਖਾਉਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਸਿਰਫ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਸੰਕੇਤ ਖਿੱਚ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਗਲਤ ਪਾਸਵਰਡ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਕਿਤੇ ਵੱਧ ਮਾੜੀ ਗੱਲ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਪਰਖ ਸਮੂਹ ਵਿੱਚ ਸਿਰਫ ਖਰਾਬ ਪਾਸਵਰਡ ਨਹੀਂ, ਅਸਮਰੱਥ ਖਾਤਾ ਅਤੇ ਸਮਾਂ ਸਮਾਪਤ ਪ੍ਰਮਾਣ ਪੱਤਰ ਵੀ ਸ਼ਾਮਲ ਕਰੋ।
ਨੀਤੀ, ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਮੈਪਿੰਗ ਇਕੱਠੇ ਬਦਲੋ
ਤਿੰਨ ਚੀਜ਼ਾਂ ਦਾ ਤਾਲਮੇਲ ਕਰੋ: ਸਰਵਰ ਨਿਰਦੇਸ਼, ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ, ਅਤੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਪਛਾਣ ਮੈਪਿੰਗ। ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰੇ ਬਦਲੋ ਤਾਂ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਅਸਫਲ ਹੁੰਦੇ ਹਨ, ਜਾਂ ਅਜਿਹੇ ਨਾਮ ਨਾਲ ਜੁੜਦੇ ਹਨ ਜਿਸ ਦੀ ਪ੍ਰਬੰਧਕ ਨੂੰ ਉਮੀਦ ਨਹੀਂ ਸੀ, ਜੋ ਵਧੇਰੇ ਮਾੜਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਫਲਤਾ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। ਗਲਤ ਪਛਾਣ ਹੇਠ ਸਫਲ ਹੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਨਾਲੋਂ ਧਿਆਨ ਦੇਣਾ ਔਖਾ ਹੈ।
ਇਸ ਮਾਰਗ ਲਈ ਦੋ ਪਰਖ ਖਾਤੇ ਰੱਖੋ, ਇੱਕ ਵੈਧ ਅਤੇ ਇੱਕ ਜਾਣਿਆ-ਖਰਾਬ, ਅਤੇ ਸਤਿਆਪਕ ਵਿੱਚ ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੋਵੇਂ ਵਰਤੋ। ਵੈਧ ਖਾਤਾ ਸੁਖਦ ਮਾਰਗ ਅਤੇ ਪਛਾਣ ਮੈਪਿੰਗ ਸਾਬਤ ਕਰਦਾ ਹੈ; ਖਰਾਬ ਵਾਲਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਰੱਦ ਕਰਨਾ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਪਰਖ ਤੁਹਾਨੂੰ ਯੋਗਤਾ ਨਿਯਮਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ, ਇਸ ਲਈ ਜੇ ਤੈਨਾਤੀ ਵਿੱਚ ਅਜਿਹੇ ਨਿਯਮ ਹਨ ਤਾਂ ਨੀਤੀਗਤ ਕਾਰਨਾਂ ਕਰਕੇ ਰੱਦ ਕੀਤਾ ਜਾਣ ਵਾਲਾ ਖਾਤਾ ਸ਼ਾਮਲ ਕਰੋ। ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਤਿੰਨੇ ਚਲਾਓ, ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਸਵੀਕਾਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਾ ਸਤਿਆਪਕ ਕੰਮ ਕਰਨ ਵਾਲੇ ਲੌਗਇਨ ਵਾਂਗ ਹੀ ਦਿਸਦਾ ਹੈ।
ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਦਰਜ ਕਰੋ, ਪ੍ਰੋਫਾਈਲ ਜੋ ਸੁਝਾਉਂਦਾ ਹੈ ਉਹ ਨਹੀਂ। ਉਹ ਦਰਜ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜੋ ਲੋਕ ਲਗਾਤਾਰ ਪੁੱਛਦੇ ਹਨ, ਭਾਵ ਇਸ ਸੇਵਾ ਨਾਲ ਕੌਣ ਜੁੜ ਸਕਦਾ ਹੈ। ਇਹ ਅਗਲੇ ਪ੍ਰਬੰਧਕ ਤੋਂ ਵੀ ਵੱਧ ਚਿਰ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਨਹੀਂ ਤਾਂ ਇਸਨੂੰ ਪੈਕਟ ਕੈਪਚਰ ਤੋਂ ਦੁਬਾਰਾ ਲੱਭ ਲਵੇਗਾ।