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

ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਸਟੇਟਸ ਕੋਡ ਪੜ੍ਹੋ

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

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

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

unit ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਕਿੱਥੇ ਹੋਣਾ ਚਾਹੁੰਦਾ ਹੈ

ਪ੍ਰਭਾਵੀ unit ਪੜ੍ਹੋ, ਤੁਸੀਂ ਜਿਸਨੂੰ ਸਥਾਪਿਤ ਸਮਝਦੇ ਹੋ ਉਹ ਫਾਈਲ ਨਹੀਂ, ਕਿਉਂਕਿ drop-in ਫਾਈਲਾਂ ਮੁੱਖ unit ਨੂੰ ਕਦੇ ਬਦਲੇ ਬਿਨਾਂ ਕੰਮਕਾਜੀ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੀਆਂ ਹਨ। show ਦਾ ਆਉਟਪੁੱਟ ਸਵਾਲ ਦਾ ਸਿੱਧਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

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

unit ਕੀ ਮੰਗਦਾ ਹੈ ਅਤੇ ਕੀ ਮੌਜੂਦ ਹੈ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਪਹਿਲਾਂ ਮੌਜੂਦ ਰਿਹਾ ਪਥ, ਹੁਣ ਕਿਤੇ ਹੋਰ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਿੰਬੋਲਿਕ ਲਿੰਕ, ਜਾਂ ਹੁਣ ਕਿਸੇ ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਨਾ ਮਿਲਦਾ ਇੰਸਟੈਂਸ ਨਾਮ—ਸਭ ਆਮ ਤਬਦੀਲੀਆਂ ਹਨ ਜੋ ਇਹੀ ਅਸਫਲਤਾ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ।

ਪਥ ਨੂੰ ਉਵੇਂ ਜਾਂਚੋ ਜਿਵੇਂ ਸੇਵਾ ਦੇਖਦੀ ਹੈ

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

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

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

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

ਮਾਲਕ ਠੀਕ ਕਰੋ, ਫਿਰ ਦੂਜੀ ਗਲਤੀ ਦੀ ਉਡੀਕ ਕਰੋ

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

ਕਨਫਿਗਰੇਸ਼ਨ ਰੁੱਖ 'ਤੇ ਇਜਾਜ਼ਤਾਂ ਵਧਾਉਣ ਜਾਂ sandbox ਹਟਾਉਣ ਦੇ ਸ਼ਾਰਟਕੱਟ ਦਾ ਵਿਰੋਧ ਕਰੋ। ਦੋਵੇਂ ਲੱਛਣ ਮਿਟਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਨਾਲ ਹੀ ਉਹ ਸੁਰੱਖਿਆਵਾਂ ਵੀ ਹਟਾ ਦਿੰਦੇ ਹਨ ਜੋ ਉੱਥੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਰੱਖੀਆਂ ਗਈਆਂ ਸਨ, ਅਤੇ ਅਗਲੀ ਅਸਫਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਨੀ ਔਖੀ ਹੋਵੇਗੀ।

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

systemd ਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸੰਦਰਭ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੰਮਕਾਜੀ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਰੂਟ ਡਾਇਰੈਕਟਰੀਆਂ ਅਤੇ sandbox ਨਾਲ ਕਿਵੇਂ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ। ਯਾਦ ਰੱਖਣ ਵਾਲਾ ਪੈਟਰਨ ਸਰਲ ਹੈ: ਹਰ ਸਟੇਟਸ ਕੋਡ ਵੱਖਰੇ ਪੜਾਅ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਐਪਲੀਕੇਸ਼ਨ ਦੀਆਂ ਆਪਣੀਆਂ ਗਲਤੀਆਂ ਹੀ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ।

ਸੰਬੰਧਿਤ ਲੇਖ