.ovpn ਫਾਈਲ ਦਾ ਸੰਪਾਦਨ ਸਰਵਰ ਉੱਤੇ MFA ਨੂੰ ਕਿਉਂ ਚਾਲੂ ਨਹੀਂ ਕਰ ਸਕਦਾ

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

ਬੇਨਤੀ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੇ ਪੁੱਛਿਆ, ਇਸ ਤੋਂ ਵੱਧ ਨਹੀਂ

.ovpn ਫਾਈਲ ਕਲਾਇੰਟ ਪਾਸੇ ਦਾ ਦਸਤਾਵੇਜ਼ ਹੈ। ਇਹ ਕਲਾਇੰਟ ਨੂੰ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਮੰਗਣ, ਉਹਨਾਂ ਨੂੰ ਕੈਸ਼ ਕਰਨ ਜਾਂ ਇਹ ਕਰਨਾ ਬੰਦ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦੀ ਹੈ। ਇਹ ਕਿਸੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਰਜਿਸਟਰ ਨਹੀਂ ਕਰ ਸਕਦੀ, PAM ਮਾਡਿਊਲ ਸਥਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਜਾਂ ਸਰਵਰ ਨੂੰ ਅਜਿਹਾ ਦੂਜਾ ਕਾਰਕ ਮੰਗਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਸਕਦੀ ਜੋ ਇਹ ਹੁਣ ਨਹੀਂ ਜਾਂਚਦਾ।

ਫੋਨ ਉੱਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਐਪ ਸਥਾਪਤ ਕਰਨ ਨਾਲ ਵੀ ਉਹ ਸੰਬੰਧ ਨਹੀਂ ਬਣਦਾ। Google Authenticator PAM ਪ੍ਰੋਜੈਕਟ OTP ਪੁਸ਼ਟੀ ਦਾ ਹਿੱਸਾ ਹੈ ਜੋ OpenVPN ਦੇ ਪਿੱਛੇ ਬੈਠ ਸਕਦਾ ਹੈ; ਇਹ ਆਯਾਤ ਕੀਤੀ ਪਰੋਫਾਈਲ ਉੱਤੇ Google ਖਾਤਾ ਲੌਗਇਨ ਚਿਪਕਾਉਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ।

ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਪਰੋਫਾਈਲ ਨਹੀਂ ਕਰ ਸਕਦੀ

TOTP ਨੂੰ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਸਮੱਗਰੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ ਐਪ ਅਤੇ ਇਸ ਦੇ ਪੁਸ਼ਟੀਕਰਤਾ ਵਿਚਕਾਰ ਸਾਂਝੀ ਹੋਵੇ। ਫੋਨ ਉੱਤੇ ਛੇ ਅੰਕ ਆਉਟਪੁੱਟ ਹਨ; ਉਹਨਾਂ ਪਿੱਛੇ ਬੀਜ ਗੁਪਤ ਹੈ, ਅਤੇ ਇਹ ਇੱਕੋ ਪਛਾਣ ਦਾ ਹੈ।

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

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

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

PAM ਸਟੈਕ ਪੜ੍ਹੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਲੋੜੀਂਦਾ ਹੈ

account required pam_permit.so ਵਰਗੀ ਲਾਈਨ ਖਾਤਾ ਯੋਗਤਾ ਲਾਗੂ ਨਹੀਂ ਕਰਦੀ ਅਤੇ ਕੋਈ ਕਾਰਕ ਨਹੀਂ ਜੋੜਦੀ। ਇਹ ਉਸ PAM ਖਾਤਾ-ਪ੍ਰਬੰਧਨ ਪੜਾਅ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਜੋ ਪੜਾਅ ਬਾਰੇ ਬਿਆਨ ਹੈ, ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰਾਂ ਬਾਰੇ ਨਹੀਂ।

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

ਕਲਾਇੰਟ ਦੀ ਕਿਰਿਆ ਨੂੰ ਸਰਵਰ ਦੇ ਡਿਜ਼ਾਈਨ ਨਾਲ ਮਿਲਾਓ

auth-user-pass

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

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

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

ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ, ਟੋਕਨ ਅਤੇ ਉਹ ਪਰਖ ਜੋ ਮਾਮਲਾ ਤੈਅ ਕਰਦੀ ਹੈ

ਪਹਿਲੇ ਸਫਲ ਲੌਗਇਨ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਪਹਿਲਾਂ ਸਵੀਕਾਰ ਕੀਤਾ ਕੋਡ ਅਗਲੀ ਪ੍ਰਮਾਣਿਕਤਾ ਉੱਤੇ ਮਿਆਦ ਪੁੱਗਿਆ ਜਾਂ ਦੁਹਰਾਅ ਵਜੋਂ ਰੱਦ ਹੋ ਸਕਦਾ ਹੈ। auth-nocache ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਰੱਖਣ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਅਤੇ MFA ਸਥਾਪਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ reneg-sec 0 ਫੋਰਮ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਕਿੰਨੀ ਵੀ ਵਾਰ ਆਵੇ, TOTP ਸਮਰਥਨ ਦੀ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਹੈ।

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

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