OpenVPN ਦੇ user ਡ੍ਰੌਪ 'ਤੇ systemd ਹਾਰਡਨਿੰਗ ਨੂੰ ਨਾ ਥੱਪੋ

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

ਦੋ ਮਾਡਲ, ਬਦਲਾਅ ਦਾ ਇੱਕ ਮਾਲਕ

ਪਹਿਲਾ ਮਾਡਲ ਡੈਮਨ ਦਾ ਹੈ। ਭਾਈਚਾਰਕ OpenVPN ਦੇ user ਅਤੇ group ਵਿਕਲਪ ਟਨਲ ਅਤੇ ਚਾਬੀਆਂ ਤਿਆਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਪਛਾਣ ਬਦਲਦੇ ਹਨ, ਅਤੇ persist-key ਦੇ ਨਾਲ persist-tun ਉਹ ਸਰੋਤ ਬਾਅਦ ਵਿੱਚ ਵੀ ਵਰਤੋਂ ਯੋਗ ਰੱਖਦੇ ਹਨ।

ਦੂਜਾ ਮਾਡਲ ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਦਾ ਹੈ। systemd ਦੀ User= ਜਾਂ Group= ਸੈਟਿੰਗ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਕਿਹੜੀ ਪਛਾਣ ਹੇਠ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਮਰੱਥਾ-ਨਿਰਦੇਸ਼ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਕੀ ਰੱਖ ਸਕਦੀ ਹੈ। ਮਾਡਲਾਂ ਵਿਚਕਾਰ ਚੋਣ ਸੁਰੱਖਿਆ ਸਵਾਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕੇਜਿੰਗ ਦਾ ਸਵਾਲ ਹੈ, ਅਤੇ ਪੈਕੇਜ ਸੰਭਾਲਣ ਵਾਲੇ ਨੇ ਇਸ ਦਾ ਜਵਾਬ ਪਹਿਲਾਂ ਹੀ ਦੇ ਦਿੱਤਾ ਹੈ। ਤੁਹਾਡਾ ਕੰਮ ਤੀਜਾ ਵਿਕਲਪ ਈਜਾਦ ਕਰਨਾ ਨਹੀਂ, ਉਹ ਜਵਾਬ ਲੱਭਣਾ ਹੈ।

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

ਤੈਅ ਕਰੋ ਕਿ ਪਛਾਣ ਕਿੱਥੇ ਬਦਲਦੀ ਹੈ

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

ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹੋ ਕਿ ਸਥਾਪਿਤ ਪੈਕੇਜ ਅਸਲ ਵਿੱਚ ਕੀ ਦਿੰਦਾ ਹੈ, ਇਸ ਦੀ drop-in ਡਾਇਰੈਕਟਰੀ ਸਮੇਤ। ਕੁਝ ਯੂਨਿਟ ਡੈਮਨ ਦੀ ਆਪਣੀ ਉਤਰਾਈ ਜਾਣ-ਬੁੱਝ ਕੇ ਛੱਡ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰਬੰਧਕ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਸ਼ੁਰੂਆਤ ਤੋਂ ਬਾਅਦ ਦੀ ਤਬਦੀਲੀ ਲਈ ਉਨ੍ਹਾਂ ਵਿਕਲਪਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਕਿਹੜਾ ਮਾਡਲ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਿਆ ਹੈ ਇਹ ਜਾਣੇ ਬਿਨਾਂ ਕੋਈ ਇੱਕ ਹਟਾਉਣਾ ਹੀ ਚੱਲਦੀ ਸੇਵਾ ਨੂੰ ਸ਼ੁਰੂ ਹੋਣੋਂ ਰੋਕਣ ਦਾ ਤਰੀਕਾ ਹੈ।

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

ਸਮਰੱਥਾਵਾਂ ਹੱਦਾਂ ਹਨ, ਦਾਨ ਨਹੀਂ

ਸਮਰੱਥਾ ਹੱਦ-ਸੈੱਟ ਦੱਸਦਾ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਵੱਧ ਤੋਂ ਵੱਧ ਕੀ ਰੱਖ ਸਕਦੀ ਹੈ। ਇਹ ਇੱਕ ਛੱਤ ਹੈ, ਅਤੇ ਉੱਥੇ ਸਮਰੱਥਾ ਸੂਚੀਬੱਧ ਕਰਨ ਨਾਲ ਆਪਣੇ ਆਪ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ, ਇਸ ਲਈ ਖੁੱਲ੍ਹੇ ਹੱਦ-ਸੈੱਟ ਵਾਲੀ ਯੂਨਿਟ ਵੀ ਟਨਲ ਬਣਾਉਣ ਵਿੱਚ ਨਾਕਾਮ ਹੋ ਸਕਦੀ ਹੈ।

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

ਸਮਰੱਥਾ ਤਦ ਹੀ ਜੋੜੋ ਜਦੋਂ ਨਾਕਾਮ ਹੋ ਰਹੀ ਕਾਰਵਾਈ ਇਸ ਨੂੰ ਪਛਾਣ ਲਵੇ। ਵਧੇਰੇ ਖੁੱਲ੍ਹਾ ਹੱਦ-ਸੈੱਟ ਅਸਲ ਕਾਰਨ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਨੂੰ ਡਿਜ਼ਾਈਨ ਦੇ ਇਰਾਦੇ ਨਾਲੋਂ ਵੱਧ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਿੱਚ ਛੱਡਦਾ ਹੈ। ਇਹ ਯੂਨਿਟ ਦੀ ਸਮੀਖਿਆ ਵੀ ਔਖੀ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਛੱਤ ਹੁਣ ਕੰਮ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦੀ। ਅਸਲ ਖ਼ਰਾਬੀ ਠੀਕ ਹੋਣ 'ਤੇ ਵਾਧੂ ਸਮਰੱਥਾ ਹਟਾ ਦਿਓ।

ਜੀਵਨ ਚੱਕਰ ਭਰ ਅਧਿਕਾਰ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ

ਹਰ ਪੜਾਅ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਨੇ ਕੀ ਕਰਨਾ ਹੈ, ਸੂਚੀਬੱਧ ਕਰੋ: ਸ਼ੁਰੂਆਤ, ਸਥਿਰ ਹਾਲਤ, ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਵਿਘਟਨ। ਇੰਟਰਫੇਸ ਬਣਾਉਣਾ, ਰਸਤੇ ਬਦਲਣਾ, ਸੁਰੱਖਿਅਤ ਚਾਬੀ ਪੜ੍ਹਨਾ ਅਤੇ ਸਹਾਇਕ ਨੂੰ ਬੁਲਾਉਣਾ ਸਭ ਇੱਕੋ ਪਲ ਜਾਂ ਇੱਕੋ ਲੋੜ ਹੇਠ ਨਹੀਂ ਹੁੰਦੇ। ਸੂਚੀ ਨੂੰ ਸਮਰੱਥਾ ਅਨੁਸਾਰ ਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪੜਾਅ ਅਨੁਸਾਰ ਲਾਓ।

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

ਸਾਂਝਾ ਨਹੀਂ, ਸਮਰਪਿਤ ਖਾਤਾ ਵਰਤੋ। OpenVPN ਦੇ ਵਿਕਾਸਕਾਰ nobody ਨੂੰ ਆਮ ਉਦਾਹਰਨ ਵਜੋਂ ਵਰਤਣ ਦੀ ਆਦਤ ਵਿਰੁੱਧ ਚੇਤਾਵਨੀ ਦਿੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਮੇਜ਼ਬਾਨ 'ਤੇ ਹੋਰ ਸੇਵਾਵਾਂ ਪਹਿਲਾਂ ਹੀ ਉਸ ਖਾਤੇ ਹੇਠ ਚੱਲ ਰਹੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਤੁਸੀਂ ਜੋ ਅਲੱਗਾਵ ਸੋਚਦੇ ਹੋ ਉਹ ਉੱਥੇ ਨਹੀਂ।

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

ਯੋਜਨਾ ਲਿਖੋ ਅਤੇ ਬਹਾਲੀ ਪਹੁੰਚ ਰੱਖੋ

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

ਸੋਧਦੇ ਸਮੇਂ ਕੰਸੋਲ ਪਹੁੰਚ ਖੁੱਲ੍ਹੀ ਰੱਖੋ, ਕਿਉਂਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਨਾਕਾਮ ਹੋਣ ਵਾਲੀ ਯੂਨਿਟ ਦੂਰੋਂ ਠੀਕ ਕਰਨੀ ਔਖੀ ਹੈ। ਬਦਲਾਅ ਨੂੰ ਪੂਰਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਅਤੇ ਪੂਰਾ ਰੀਬੂਟ ਪਰਖੋ। ਮੁੜ-ਸ਼ੁਰੂਆਤ ਝੱਲਣ ਵਾਲੀ ਯੂਨਿਟ ਨੈੱਟਵਰਕ ਚਾਲੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵੀ ਨਾਕਾਮ ਹੋ ਸਕਦੀ ਹੈ।

ਸਫਲਤਾ ਇੱਕ ਸਮਝਿਆ ਘੱਟੋ-ਘੱਟ-ਅਧਿਕਾਰ ਜੀਵਨ ਚੱਕਰ ਹੈ, ਅਜਿਹੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਜੋ ਸੰਜੋਗ ਨਾਲ ਗੈਰ-root ਨਾਮ ਹੇਠ ਚੱਲ ਰਹੀ ਹੋਵੇ।