ਸੁਧਾਰ: OpenVPN ਮਿਆਰੀ ਇਨਪੁੱਟ ਤੋਂ Auth ਵਰਤੋਂਕਾਰ ਨਾਮ ਪੜ੍ਹ ਨਹੀਂ ਸਕਿਆ
OpenVPN ਦੀ «could not read Auth username from stdin» ਗਲਤੀ ਇੱਕ ਸਥਾਨਕ ਇਨਪੁੱਟ ਅਸਫਲਤਾ ਹੈ। ਸੇਵਾ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸਰੋਤ ਦਿਓ; script-security ਨਾਲ ਇਸ ਦਾ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ।
could not read Auth username from stdin ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਸਦਾ ਹੈ ਅਤੇ ਹੈ ਨਹੀਂ। OpenVPN ਨੇ ਮਿਆਰੀ ਇਨਪੁੱਟ ਤੋਂ ਵਰਤੋਂਕਾਰ ਨਾਮ ਮੰਗਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਪੜ੍ਹਨਯੋਗ ਕੁਝ ਨਹੀਂ ਮਿਲਿਆ ਅਤੇ ਸਰਵਰ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੁਕ ਗਿਆ। ਖਾਤਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਹੋ ਸਕਦਾ ਹੈ; ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਪੁੱਛਣ ਵਾਲਾ ਕੋਈ ਨਹੀਂ।
ਇਸ ਲਈ ਪਹਿਲਾ ਲਾਭਦਾਇਕ ਕਦਮ ਇਹ ਪੱਕਾ ਕਰਨਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕੀ ਪੜ੍ਹ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ ਕਨੈਕਸ਼ਨ ਦੁਬਾਰਾ ਅਜ਼ਮਾਉਣਾ ਜਾਂ ਸਰਵਰ-ਪਾਸੇ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਬਦਲਣਾ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਅਸਫਲ ਜਾਂਚ 'ਤੇ ਰੁਕੋ।
ਗਲਤੀ ਨੂੰ ਸਥਾਨਕ ਇਨਪੁੱਟ ਅਸਫਲਤਾ ਵਜੋਂ ਪੜ੍ਹੋ
ਜਦੋਂ auth-user-pass ਫਾਈਲ ਆਰਗਿਊਮੈਂਟ ਤੋਂ ਬਿਨਾਂ ਆਉਂਦਾ ਹੈ, ਕਲਾਇੰਟ ਪੁੱਛਣ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਇੰਟਰਐਕਟਿਵ ਸ਼ੈੱਲ ਵਿੱਚ ਉਹ ਪ੍ਰੌਂਪਟ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਟਰਮੀਨਲ ਹੁੰਦਾ ਹੈ। systemd, cron ਕੰਮ ਜਾਂ ਕੰਟੇਨਰ ਹੇਠ ਮਿਆਰੀ ਇਨਪੁੱਟ ਆਮ ਤੌਰ 'ਤੇ ਖਾਲੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪੜ੍ਹਤ ਤੁਹਾਡੇ ਦੇਖ ਰਹੇ ਗਲਤੀ ਨਾਲ ਤੁਰੰਤ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ।
ਸੁਨੇਹਾ ਅਸਫਲ ਹੋਏ ਖੇਤਰ ਦਾ ਨਾਮ ਵੀ ਦੱਸਦਾ ਹੈ, ਵਰਤੋਂਕਾਰ ਨਾਮ ਜਾਂ ਪਾਸਵਰਡ, ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪੜ੍ਹਤ ਕਿੰਨੀ ਦੂਰ ਗਈ। ਵਰਤੋਂਕਾਰ ਨਾਮ ਨਾ ਹੋਣ ਦਾ ਅਰਥ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਕੁਝ ਵੀ ਨਹੀਂ ਪੜ੍ਹ ਸਕੀ। ਸਫਲ ਵਰਤੋਂਕਾਰ ਨਾਮ ਤੋਂ ਬਾਅਦ ਪਾਸਵਰਡ ਨਾ ਹੋਣ ਦਾ ਅਰਥ ਹੈ ਕਿ ਦੋ ਪੜ੍ਹਤਾਂ ਵਿਚਕਾਰ ਇਨਪੁੱਟ ਪ੍ਰਵਾਹ ਖ਼ਤਮ ਹੋ ਗਿਆ, ਜੋ ਅੱਧੀ ਲਿਖੀ ਫਾਈਲ ਜਾਂ ਬੰਦ ਪਾਈਪ ਲਈ ਆਮ ਹੈ।
ਹੋਰ ਕੁਝ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਪੱਕਾ ਕਰੋ। ਇਸ ਨੂੰ ਉਸੇ ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਉਸੇ ਵਰਤੋਂਕਾਰ ਨਾਲ ਅਗਲੇ ਭਾਗ ਵਿੱਚ ਚਲਾਓ ਅਤੇ ਦੇਖੋ ਕਿ ਪ੍ਰੌਂਪਟ ਆਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਪਰ ਸੇਵਾ ਮੈਨੇਜਰ ਹੇਠ ਨਹੀਂ, ਤਾਂ ਫਰਕ ਇਨਪੁੱਟ ਸਰੋਤ ਵਿੱਚ ਹੈ, ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਵਿੱਚ ਨਹੀਂ। unit ਫਾਈਲ ਅਤੇ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਵਾਤਾਵਰਣ ਦੀ ਤੁਰੰਤ ਤੁਲਨਾ ਆਮ ਤੌਰ 'ਤੇ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਟਰਮੀਨਲ ਦਿੰਦਾ ਹੈ।
ਸੇਵਾ ਨੂੰ ਸਮਰਥਿਤ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸਰੋਤ ਦਿਓ
ਨਿਗਰਾਨੀ ਤੋਂ ਬਿਨਾਂ ਚਲਾਉਣ ਲਈ ਸਮਰਥਿਤ ਸਰੋਤ ਇੱਕ ਪ੍ਰਮਾਣ ਪੱਤਰ ਫਾਈਲ ਹੈ ਜੋ ਆਰਗਿਊਮੈਂਟ ਵਜੋਂ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ auth-user-pass ਨੂੰ। ਫਾਈਲ ਸਾਦੇ ਟੈਕਸਟ ਵਜੋਂ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ: ਪਹਿਲੀ ਲਾਈਨ ਵਰਤੋਂਕਾਰ ਨਾਮ ਹੈ, ਦੂਜੀ ਪਾਸਵਰਡ। ਇਸ ਵੱਲ ਪੂਰਨ ਪਥ ਨਾਲ ਇਸ਼ਾਰਾ ਕਰੋ, ਜਿਵੇਂ /etc/openvpn/client/creds , ਤਾਂ ਜੋ ਸੇਵਾ ਖਾਤੇ ਦੀ ਕਾਰਜ ਡਾਇਰੈਕਟਰੀ ਨਿਰਦੇਸ਼ ਦਾ ਅਰਥ ਨਾ ਬਦਲ ਸਕੇ।
ਇਜਾਜ਼ਤਾਂ ਪਥ ਜਿੰਨੀਆਂ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਫਾਈਲ ਕਲਾਇੰਟ ਚਲਾਉਣ ਵਾਲੇ ਖਾਤੇ ਲਈ ਪੜ੍ਹਨਯੋਗ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਸਾਰਿਆਂ ਲਈ ਨਹੀਂ, ਅਤੇ ਇਹ ਸੇਵਾ ਖਾਤੇ ਜਾਂ ਸੇਵਾ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਸਮੂਹ ਵਾਲੇ root ਦੀ ਮਾਲਕੀ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਮੱਗਰੀ ਛਾਪੇ ਬਿਨਾਂ ਉਸ ਖਾਤੇ ਵਜੋਂ ਪੜ੍ਹਨਯੋਗਤਾ ਜਾਂਚੋ।
ਸਾਪੇਖਿਕ ਪਥ ਸ਼ਾਂਤ ਅਸਫਲਤਾ ਦਾ ਢੰਗ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ systemd ਪ੍ਰਕਿਰਿਆ ਕਿਤੇ ਹੋਰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਜੋ ਫਾਈਲ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਵਿੱਚ ਹੱਲ ਹੁੰਦੀ ਹੈ ਉਹ ਸੇਵਾ ਲਈ ਹੱਲ ਨਹੀਂ ਹੁੰਦੀ। ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਸਥਿਰ ਥਾਂ 'ਤੇ ਲਿਜਾਓ ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਪੂਰਨ ਹਵਾਲਾ ਦਿਓ। ਫਿਰ ਸੇਵਾ ਇੱਕ ਵਾਰ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਉਹੀ ਪਥ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪ੍ਰੋਫਾਈਲ ਐਡੀਟਰ ਦੇ ਦ੍ਰਿਸ਼ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ।
ਜੇ ਤੈਨਾਤੀ ਲਈ ਇੱਕ-ਵਾਰੀ ਕੋਡ ਜਾਂ ਹੋਰ ਇੰਟਰਐਕਟਿਵ ਚੁਣੌਤੀ ਲੋੜੀਂਦੀ ਹੈ, ਤਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਦਾ ਵਰਕਫਲੋ ਇਸ ਨੂੰ ਨਿਗਰਾਨੀ ਤੋਂ ਬਿਨਾਂ ਸੱਚਮੁੱਚ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਥਿਰ ਪਾਸਵਰਡ ਵਾਲੀ ਫਾਈਲ ਘੁੰਮਦੇ ਕੋਡ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੀ, ਅਤੇ ਜਿਸ ਪ੍ਰੌਂਪਟ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਉਸ ਨੂੰ ਦੁਬਾਰਾ ਅਜ਼ਮਾਉਣ ਨਾਲ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਵਧਦੀ।
script-security ਸਹਾਇਤਾ ਕਿਉਂ ਨਹੀਂ ਕਰੇਗਾ
script-security ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਸਕ੍ਰਿਪਟਾਂ ਚਲਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕਿੰਨਾ ਦੇ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਵਾਤਾਵਰਣ ਚਰ ਰਾਹੀਂ ਸਕ੍ਰਿਪਟ ਨੂੰ ਪਾਸਵਰਡ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਅਸਲ ਵਿੱਚ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ, ਇਸ ਬਾਰੇ ਇਹ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਸੁਨੇਹੇ ਵਿੱਚ Auth ਦਾ ਜ਼ਿਕਰ ਹੋਣ ਕਾਰਨ ਇਸ ਨੂੰ ਉੱਚੇ ਪੱਧਰ 'ਤੇ ਲਿਜਾਣਾ ਆਮ ਪ੍ਰਤੀਕਿਰਿਆ ਹੈ, ਪਰ ਇਹ ਇਨਪੁੱਟ ਸਰੋਤ ਦੀ ਥਾਂ ਸਕ੍ਰਿਪਟ ਇਜਾਜ਼ਤਾਂ ਬਦਲਦਾ ਹੈ ਅਤੇ ਵਧਾਉਂਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕੀ ਚਲਾ ਸਕਦਾ ਹੈ। ਜੇ ਸਹਾਇਕ ਸਕ੍ਰਿਪਟ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਇਨਪੁੱਟ ਸਰੋਤ ਸੁਧਾਰੋ ਅਤੇ ਸੁਰੱਖਿਆ ਪੱਧਰ ਨੂੰ ਤੈਨਾਤੀ ਲਈ ਲੋੜੀਂਦੇ ਸਭ ਤੋਂ ਘੱਟ ਮੁੱਲ 'ਤੇ ਰੱਖੋ।
ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਵੈਧ ਵਿਕਲਪ ਹੈ। ਫਰੰਟਐਂਡ ਇਸ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ, ਪ੍ਰਮਾਣ ਪੱਤਰ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਨਾਮ ਤੇ ਪਾਸਵਰਡ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ; ਕੁਝ GUI ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਸ ਨੂੰ ਸਥਾਨਕ ਪਤੇ ਨਾਲ ਬੰਨ੍ਹੋ, ਪ੍ਰਬੰਧਨ ਪਾਸਵਰਡ ਫਾਈਲ ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰੋ ਅਤੇ ਸੀਮਿਤ ਕਰੋ ਕਿ ਕੌਣ ਜੁੜ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਕਲਾਇੰਟ ਲਈ ਨਿਯੰਤਰਣ ਚੈਨਲ ਹੈ।
ਕਲਾਇੰਟ ਵੱਲੋਂ ਫਾਈਲ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਅਗਲੇ ਪੜਾਅ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਇੱਕ ਵਾਰ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪੜ੍ਹ ਸਕੇ, ਤਾਂ ਅਗਲੀ ਅਸਫਲਤਾ ਸਰਵਰ ਨਾਲ ਅਸਲ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਹੈ, ਅਤੇ ਇਸ ਦੇ ਸੁਨੇਹੇ ਦਾ ਅਰਥ ਵੱਖਰਾ ਹੈ। ਉਸ ਪੜਾਅ 'ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਅਸਫਲਤਾ ਦਾ ਅਰਥ ਹੈ ਕਿ ਸਰਵਰ ਨੇ ਖਾਤਾ ਰੱਦ ਕੀਤਾ; ਚੁਣੌਤੀ ਜਵਾਬ ਦਾ ਅਰਥ ਹੈ ਕਿ ਸਰਵਰ ਨੂੰ ਕੋਈ ਹੋਰ ਕਾਰਕ ਚਾਹੀਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਉਸੇ ਸਮੱਸਿਆ ਦੀ ਪੁਨਰਾਵ੍ਰਿੱਤੀ ਨਹੀਂ, ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਮੰਨੋ।
ਪੂਰਾ ਪਥ ਉਸੇ ਤਰ੍ਹਾਂ ਜਾਂਚੋ ਜਿਵੇਂ ਸੇਵਾ ਇਸ ਨੂੰ ਚਲਾਏਗੀ: ਉਹੀ ਖਾਤਾ, ਉਹੀ ਕਾਰਜ ਡਾਇਰੈਕਟਰੀ, ਉਹੀ unit ਵਾਤਾਵਰਣ। ਜੋ ਕਨੈਕਸ਼ਨ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਉਹ ਸੰਕੇਤ ਹੈ ਕਿ ਵਾਤਾਵਰਣ ਚਰ ਜਾਂ ਟਰਮੀਨਲ ਅਜੇ ਵੀ ਪ੍ਰਵਾਹ ਦਾ ਹਿੱਸਾ ਹੈ।
ਫਿਰ ਭੇਦਾਂ ਨੂੰ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਉਨ੍ਹਾਂ ਦੀ ਥਾਂ ਹੈ। ਕਮਾਂਡ-ਲਾਈਨ ਆਰਗਿਊਮੈਂਟਾਂ ਵਿੱਚ ਪਾਸਵਰਡ ਪ੍ਰਕਿਰਿਆ ਸਾਰਣੀ ਵਿੱਚ ਦਿਸਦੇ ਹਨ, ਅਤੇ ਡੀਬੱਗ ਆਉਟਪੁੱਟ ਵਿੱਚ ਪਾਸਵਰਡ ਟਿਕਟਾਂ ਵਿੱਚ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ। ਸੁਰੱਖਿਅਤ ਫਾਈਲ ਜਾਂ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਵਰਤੋ, ਲੌਗ ਉਸ ਪੱਧਰ 'ਤੇ ਰੱਖੋ ਜੋ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਾ ਦੁਹਰਾਏ, ਅਤੇ ਜਦੋਂ ਪਹੁੰਚ ਵਾਲਾ ਕੋਈ ਛੱਡੇ ਤਾਂ ਫਾਈਲ ਬਦਲੋ।
ਜਾਂਚ ਸੂਚੀ: ਪੂਰਨ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪਥ, ਸੇਵਾ ਖਾਤੇ ਵਜੋਂ ਪੜ੍ਹਨਯੋਗ, ਟਰਮੀਨਲ ਦੀ ਲੋੜ ਨਹੀਂ, script-security ਆਪਣੇ ਘੱਟੋ-ਘੱਟ 'ਤੇ, ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਸਿਰਫ਼ ਜੇ ਬੱਧਾ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਹੋਵੇ, ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਸਰਵਰ ਪ੍ਰਤੀਕਿਰਿਆ ਨੂੰ ਵੱਖਰੀ ਘਟਨਾ ਮੰਨਣਾ।