OpenVPN PAM: login ਆਰਗਿਊਮੈਂਟ ਸੇਵਾ ਹੈ, ਵਰਤੋਂਕਾਰ ਨਹੀਂ

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

ਦੂਜਾ ਸ਼ਬਦ ਕੀ ਚੁਣਦਾ ਹੈ

ਕੌਨਫਿਗਰੇਸ਼ਨ ਲਾਈਨ ਇੱਕ ਪਲੱਗਇਨ ਪਾਥ ਅਤੇ ਇੱਕ ਆਰਗਿਊਮੈਂਟ ਲੈਂਦੀ ਹੈ:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

ਉਹ ਆਰਗਿਊਮੈਂਟ ਸੇਵਾ ਨਾਂ ਵਜੋਂ PAM ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ /etc/pam.d/openvpn ਵਿੱਚਲਾ ਸਟੈਕ ਚੱਲਦਾ ਹੈ। ਉੱਥੇ login ਲਿਖੋ ਤਾਂ ਇਸ ਦੀ ਥਾਂ ਅੰਤਰਕਿਰਿਆਤਮਕ ਲੌਗਇਨ ਨੀਤੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਤੁਹਾਡੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਵਿੱਚ ਉਹ ਨੀਤੀ ਜਿਹੜੇ ਮਾਡਿਊਲ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ ਉਹਨਾਂ ਸਮੇਤ।

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

ਸਟੈਕ ਅਸਲ ਵਿੱਚ ਖਾਤੇ ਕਿੱਥੋਂ ਪੜ੍ਹਦਾ ਹੈ

PAM ਇੱਕ ਡਿਸਪੈਚਰ ਹੈ। ਸੇਵਾ ਫ਼ਾਈਲ ਮਾਡਿਊਲ ਕ੍ਰਮ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਦੇ ਸਕਣ ਵਾਲਾ ਪਹਿਲਾ ਹੀ ਨਤੀਜਾ ਤੈਅ ਕਰਦਾ ਹੈ। pam_unix ਬੁਲਾਉਣ ਵਾਲਾ ਸਟੈਕ ਸਥਾਨਕ ਖਾਤੇ ਪੜ੍ਹਦਾ ਹੈ; LDAP ਜਾਂ RADIUS ਮਾਡਿਊਲ ਬੁਲਾਉਣ ਵਾਲਾ ਸਟੈਕ ਪ੍ਰਮਾਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਿਸੇ ਹੋਰ ਥਾਂ ਭੇਜਦਾ ਹੈ।

ਸੇਵਾ ਨਾਂ ਜਿਸ ਫ਼ਾਈਲ ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਹੈ ਉਹ, ਉਸ ਵੱਲੋਂ ਸ਼ਾਮਲ ਕੀਤੇ ਸਭ ਸਮੇਤ ਪੜ੍ਹੋ:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

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

ਇੱਕ ਕੋਸ਼ਿਸ਼, ਦੋ ਲੌਗ

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

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

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

pamtester openvpn alice authenticate

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

ਸਮਰਪਿਤ ਸੇਵਾ login ਸੋਧਣ ਨਾਲੋਂ ਬਿਹਤਰ

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

ਲੋੜੀਂਦੇ ਮਾਡਿਊਲ ਇੱਕ ਛੋਟੀ ਸੇਵਾ ਫ਼ਾਈਲ ਵਿੱਚ ਕਾਪੀ ਕਰੋ, ਕ੍ਰਮ ਸਪਸ਼ਟ ਰੱਖੋ, ਅਤੇ ਮਾਲਕ ਕੌਣ ਹੈ ਲਿਖੋ। ਪਾਸਵਰਡ ਰੀਸੈਟ ਦਾ ਅਸਰ ਨਾ ਹੋਣ ਵਾਂਗ ਲੱਗੇ ਤਾਂ ਜਾਂਚਣ ਵਾਲੀ ਉਹੀ ਫ਼ਾਈਲ ਹੈ।

ਕਲਾਇੰਟ ਕੀ ਭੇਜਦਾ ਹੈ, ਕੀ ਨਹੀਂ ਭੇਜਦਾ

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

ਵਰਤੋਂਕਾਰ ਨਾਂ ਅਤੇ ਪਾਸਵਰਡ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਇਕੱਠੇ ਰਹਿ ਸਕਦੇ ਹਨ, ਅਤੇ PAM ਸਮਰੱਥ ਕਰਨਾ ਸਰਟੀਫਿਕੇਟ ਪਰਖਣਾ ਬੰਦ ਕਰਨ ਦਾ ਕਾਰਨ ਨਹੀਂ। ਤੈਨਾਤੀ ਵੱਲੋਂ ਲੋੜੇ ਪੱਧਰ ਕਾਇਮ ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਖਾਤਾ ਸਰੋਤ ਠੀਕ ਕਰੋ।

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