PAM ਮਾਡਿਊਲ ਅਣਜਾਣ ਹੈ: ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਫੇਲ੍ਹ ਹੋਈ
ਸੁਨੇਹਾ ਸਾਂਝੀ ਵਸਤੂ ਅਤੇ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਦਾ ਨਾਂ ਲੈਂਦਾ ਹੈ, ਪਾਸਵਰਡ ਦਾ ਨਹੀਂ। ਜਿਸ ਪ੍ਰਕਿਰਿਆ ਨੇ ਇਸ ਨੂੰ ਲਾਗ ਕੀਤਾ ਉਹ ਲੱਭੋ, ਫਿਰ ਲੋਡਿੰਗ, ਚਿੰਨ੍ਹ ਅਤੇ ਸਟੈਕ ਦੀਆਂ ਗਰੰਟੀਆਂ ਜਾਂਚੋ।
ਉਸ ਵਾਕ ਨੂੰ ਪਾਸਵਰਡ ਬਾਰੇ ਨਹੀਂ, ਸਗੋਂ ਸਾਂਝੀ ਵਸਤੂ ਅਤੇ ਫੰਕਸ਼ਨ ਪੁਆਇੰਟਰ ਬਾਰੇ ਬਿਆਨ ਵਜੋਂ ਪੜ੍ਹੋ। ਉਹੀ ਸ਼ਬਦ ਇੱਕ OpenVPN ਪਲੱਗਇਨ ਤੋਂ, ਇੱਕ ਸੇਵਾ ਲਈ ਲੋਡ ਕੀਤੇ PAM ਸਟੈਕ ਤੋਂ, ਜਾਂ RADIUS ਡੈਮਨ ਦੇ ਅੰਦਰੋਂ ਆ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਹ ਤਿੰਨ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ ਹਨ। ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਤੈਅ ਕਰੋ।
ਹੇਠਲੀਆਂ ਜਾਂਚਾਂ ਮੰਨਦੀਆਂ ਹਨ ਕਿ ਸੁਨੇਹਾ VPN ਲਾਗਇਨ 'ਤੇ Linux-PAM ਏਕੀਕਰਨ ਰਾਹੀਂ ਆਇਆ। ਜੇ ਇਹ RADIUS ਸਰਵਰ ਦੀ ਆਪਣੀ ਸੰਰਚਨਾ ਤੋਂ ਆਇਆ ਹੈ, ਤਾਂ ਉਸੇ ਡੈਮਨ ਦੇ ਸਬੂਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ।
ਪੈਕੇਜ ਦਾ ਨਾਂ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਂ ਲਵੋ
ਤਿੰਨ ਹਿੱਸਿਆਂ ਨੂੰ ਮਾਡਿਊਲ ਕਿਹਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਬਦਲਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। OpenVPN ਪ੍ਰਮਾਣੀਕਰਨ ਪਲੱਗਇਨ VPN ਡੈਮਨ ਲੋਡ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹ ਉਸ ਡੈਮਨ ਦਾ ਕਾਲਬੈਕ ਇੰਟਰਫੇਸ ਲਾਗੂ ਕਰਦਾ ਹੈ। PAM ਮਾਡਿਊਲ ਇੱਕ ਸਾਂਝੀ ਵਸਤੂ ਹੈ, ਜਿਸ ਨੂੰ libpam ਕਿਸੇ ਨਾਮਿਤ ਸੇਵਾ ਲਈ ਲੋਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੋ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਲਾਗੂ ਕਰਦਾ ਹੈ: pam_sm_authenticate। FreeRADIUS ਮਾਡਿਊਲ ਉਸ ਡੈਮਨ ਦੀ ਆਪਣੀ ਸੰਰਚਨਾ ਦਾ ਹਿੱਸਾ ਹੈ। ਉਹੀ ਸ਼ਬਦਾਂ ਵਾਲਾ ਸੁਨੇਹਾ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਤੋਂ ਵੀ ਆ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜੀ ਲਾਗ ਲਾਈਨ ਨੇ ਇਸ ਨੂੰ ਬਣਾਇਆ।
ਇੱਕ ਫੇਲ੍ਹ ਹੋਏ ਯਤਨ ਦੀ ਸਮਾਂ-ਮੋਹਰ VPN ਲਾਗ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰਮਾਣੀਕਰਨ ਲਾਗ ਵਿਚਕਾਰ ਮਿਲਾਓ, ਫਿਰ ਸਾਰਾਂਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਲਾਈਨਾਂ ਪੜ੍ਹੋ। ਖਾਸ ਲੋਡਰ ਸੁਨੇਹਾ ਆਮ ਤੌਰ 'ਤੇ ਉੱਥੇ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦਾ ਹੈ।
ਲੋਡਿੰਗ ਗਲਤੀ ਪੜ੍ਹੋ, ਫਿਰ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ
PAM ਅਣਜਾਣ ਮਾਡਿਊਲ ਦੀ ਸੂਚਨਾ ਤਦ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਚੁਣੀ ਸਾਂਝੀ ਵਸਤੂ ਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਜਾਂ ਜਦੋਂ ਲੋਡ ਕੀਤੀ ਵਸਤੂ ਉਹ ਫੰਕਸ਼ਨ ਨਹੀਂ ਦਿੰਦੀ ਜੋ ਉਸ ਸਟੈਕ ਐਂਟਰੀ ਨੂੰ ਲੋੜੀਂਦਾ ਹੈ। ਇਹ ਵੱਖਰੀਆਂ ਮੁਰੰਮਤਾਂ ਹਨ: ਪਹਿਲੀ ਪਥ, ਪੈਕੇਜਿੰਗ ਜਾਂ ABI ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਦੂਜੀ ਨਾ-ਮਿਲਦਾ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਹੈ। ਪ੍ਰਮਾਣੀਕਰਨ ਲਾਈਨ ਨੂੰ ਲੋੜ ਹੈ pam_sm_authenticate ਜਦਕਿ ਖਾਤਾ ਲਾਈਨ ਨੂੰ ਲੋੜ ਹੈ pam_sm_acct_mgmt, ਅਤੇ ਜੋ ਲਾਇਬ੍ਰੇਰੀ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਲਾਗੂ ਕਰਦੀ ਹੈ ਉਹ ਦੂਜੇ 'ਤੇ ਫੇਲ੍ਹ ਹੋਵੇਗੀ, ਜਿਵੇਂ ਭੇਜਣ ਵਾਲੇ ਦਾ ਕੋਡ ਦਿਖਾਉਂਦਾ ਹੈ। ਡਿਸਕ 'ਤੇ ਫਾਈਲ ਮਿਲਣਾ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਕਿਸੇ ਹੋਰ ਵੰਡ ਜਾਂ CPU ਆਰਕੀਟੈਕਚਰ ਤੋਂ ਸਮਾਨ ਨਾਂ ਦੀ ਲਾਇਬ੍ਰੇਰੀ ਲੈਣਾ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਪਣੇ libpam ਵਿਰੁੱਧ ਕਦੇ ਨਾ-ਜਾਂਚਿਆ ਮਾਡਿਊਲ ਲੋਡ ਕਰਦਿਆਂ ਛੱਡ ਸਕਦਾ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਛਿਤ ਪਥ ਦੇ ਮਾਲਕ ਪੈਕੇਜ ਅਤੇ ਫਾਈਲ ਦੀ ਅਸਲ ਆਰਕੀਟੈਕਚਰ ਜਾਂਚੋ।
ਸਟੈਕ ਵੱਲੋਂ ਦਿੱਤੀਆਂ ਗਰੰਟੀਆਂ ਕਾਇਮ ਰੱਖੋ
ਇਸ ਗਲਤੀ ਨੂੰ ਚੁੱਪ ਕਰਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਸਭ ਤੋਂ ਮਾੜਾ ਵੀ ਹੈ: ਲੋੜੀਂਦੇ ਮਾਡਿਊਲ ਨੂੰ ਚੋਣਵਾਂ ਚਿੰਨ੍ਹਿਤ ਕਰਨਾ, ਖਾਤਾ ਪੜਾਅ ਮਿਟਾਉਣਾ, ਜਾਂ ਬਿਨਾਂ ਸ਼ਰਤ ਇਜਾਜ਼ਤ ਪਾਉਣਾ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਫੇਲ੍ਹ ਜਾਂਚ ਨੂੰ ਗੈਰਹਾਜ਼ਰ ਜਾਂਚ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਲਾਗਇਨ ਉਨ੍ਹਾਂ ਕਾਰਨਾਂ ਕਰਕੇ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਨਹੀਂ ਚਾਹੇ ਸਨ। ਪਾਸਵਰਡ ਰੀਸੈਟ ਅਤੇ ਸਾਂਝੇ ਭੇਤ ਦੀ ਤਬਦੀਲੀ ਵੀ ਗੁੰਮ ਫੰਕਸ਼ਨ ਨਹੀਂ ਦਿੰਦੇ, ਕਿਉਂਕਿ ਫੇਲ੍ਹ ਕੋਈ ਵੀ ਪ੍ਰਮਾਣ ਬੈਕਐਂਡ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦੀ ਹੈ।
ਬਹੁ-ਮਾਡਿਊਲ ਸਟੈਕ ਨੇ ਫੇਲ੍ਹ ਐਂਟਰੀ ਤੋਂ ਪਹਿਲਾਂ ਕੋਈ ਹੋਰ ਬੈਕਐਂਡ ਚਲਾਇਆ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਗਲਤੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕੋਈ RADIUS ਬੇਨਤੀ ਨਹੀਂ ਭੇਜੀ ਗਈ।
ਮਾਡਿਊਲ ਨਹੀਂ, ਲਾਗਇਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਵਿਸੰਗਤੀ ਦੀ ਮੁਰੰਮਤ ਤੋਂ ਬਾਅਦ ਅਸਲ ਦਾਖਲਾ ਮਾਰਗ ਦੀ ਪਰਖ ਕਰੋ। ਵੈਧ ਖਾਤਾ ਸਫਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਵੈਧ ਪ੍ਰਮਾਣ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਵਰਜਿਤ ਖਾਤਾ ਅਜੇ ਵੀ ਰੱਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਵਾਧੂ ਕਾਰਕ ਦੀ ਕੋਈ ਵੀ ਲੋੜ ਅਜੇ ਵੀ ਲਾਗੂ ਹੈ, ਕਿਉਂਕਿ ਪੜਾਅ ਛੱਡਣ ਵਾਲਾ ਮੁਰੰਮਤ ਕੀਤਾ ਸਟੈਕ ਗਾਹਕ ਵੱਲੋਂ ਸਫਲਤਾ ਵਾਂਗ ਦਿਸਦਾ ਹੈ।
ਮਾਡਿਊਲ ਦਾ ਸਾਫ਼ ਲੋਡ ਹੋਣਾ ਤਰੱਕੀ ਹੈ, ਪੂਰੀ ਹੋਈ ਪਰਖ ਨਹੀਂ।
ਕਿਹੜਾ ਸੇਵਾ ਨਾਂ, ਕਿਹੜੀਆਂ ਨੀਤੀ ਫਾਈਲਾਂ ਅਤੇ ਕਿਹੜੇ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਸ਼ਾਮਲ ਸਨ, ਇਹ ਸਬੂਤ ਵਜੋਂ ਵਰਤੇ ਇੱਕੋ ਯਤਨ ਸਮੇਤ ਦਰਜ ਕਰੋ। ਉਹੀ ਦਰਜ ਰਿਕਾਰਡ ਅਗਲੀ ਘਟਨਾ ਨੂੰ ਪੁਰਾਤੱਤਵ ਅਭਿਆਸ ਦੀ ਥਾਂ ਖੋਜ ਬਣਾਉਂਦਾ ਹੈ।