ਕਿਹੜੀ openvpn ਬਾਈਨਰੀ ਚੱਲ ਰਹੀ ਹੈ? ਲਾਂਚ ਪਾਥ ਜਾਂਚੋ

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

ਸੇਵਾ ਜੋ ਪਾਥ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਟਰਮੀਨਲ ਅਤੇ systemd ਯੂਨਿਟ ਐਗਜ਼ਿਕਿਊਟੇਬਲਾਂ ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਸੁਲਝਾਉਂਦੇ। shell PATH ਵਿੱਚ ਖੋਜਦਾ ਹੈ; ਯੂਨਿਟ ਇੱਕ ਪਾਥ ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ, ਅਤੇ drop-in ਓਵਰਰਾਈਡ ਉਸ ਫਾਈਲ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਹੀ ਉਸ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਪੜ੍ਹ ਰਹੇ ਹੋ। ਇਹੀ ਫਰਕ ਇਸ ਕੰਮ ਦੀ ਜ਼ਿਆਦਾਤਰ ਉਲਝਣ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਇਹ ਵੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਮੁਰੰਮਤ ਨੂੰ ਕਿਹੜੀ ਫਾਈਲ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣਾ ਹੈ।

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

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸੁਲਝਾਇਆ ਪਾਥ ਲਿਖ ਲਓ।

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

ਕਮਾਂਡ ਦੇ ਨਾਮ ਦੀ ਸੇਵਾ ਦੇ ਪਾਥ ਨਾਲ ਤੁਲਨਾ ਕਰੋ

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

ਅਹਿਮ ਗੱਲ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਕਿਹੜਾ ਮਾਲਕ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜੇ ਯੂਨਿਟ /usr/local/sbin/openvpn-wrapper ਚਲਾਉਂਦੀ ਹੈ ਜਦੋਂ ਕਿ ਤੁਹਾਡਾ shell /usr/sbin/openvpn ਸੁਲਝਾਉਂਦਾ ਹੈ, ਤਾਂ ਦੂਜੀ ਫਾਈਲ ਠੀਕ ਕਰਨ ਨਾਲ ਸੇਵਾ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

ਪੁੱਛੋ ਕਿ ਹਰ ਉਮੀਦਵਾਰ ਕਿਸ ਪੈਕੇਜ ਦਾ ਹੈ, ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਫਾਈਲ ਪੈਕੇਜ-ਸੰਭਾਲੀ ਹੈ ਜਾਂ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਰੱਖੀ ਗਈ ਹੈ। ਮਾਲਕ ਪੈਕੇਜ ਤੋਂ ਬਿਨਾਂ ਫਾਈਲ ਉਹ ਫਾਈਲ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਉੱਥੇ ਰੱਖੀ ਹੈ, ਅਤੇ ਇਹ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ, ਮਾਲਕ ਅਤੇ ਕਾਰਨ ਦੀ ਹੱਕਦਾਰ ਹੈ। ਉਲਟੀ ਗਲਤੀ ਵੀ ਆਮ ਹੈ: ਪੁਰਾਣੀ ਸੰਭਾਲੀ ਬਾਈਨਰੀ ਨਾਲ ਪੈਕੇਜ ਫਾਈਲ ਉੱਤੇ ਲਿਖਣਾ, ਕਿਉਂਕਿ ਫੋਰਮ ਪੋਸਟ ਨੇ ਉਹੀ ਡਾਇਰੈਕਟਰੀ ਵਰਤੀ ਸੀ।

ਪੈਕੇਜ ਫਾਈਲਾਂ ਬਾਰੇ ਪੈਕੇਜ ਡੇਟਾਬੇਸ ਨੂੰ ਬੋਲਣ ਦਿਓ

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

ਪੁਸ਼ਟੀ ਚਲਾਓ ਅਤੇ ਖਾਲੀ ਨਤੀਜੇ ਨੂੰ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸਬੂਤ ਮੰਨਣ ਦੀ ਥਾਂ ਨਤੀਜਾ ਪੜ੍ਹੋ।

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

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

ਮੁਰੰਮਤ ਤੋਂ ਪਹਿਲਾਂ ਹਾਲਤ ਦਰਜ ਕਰੋ

ਸੁਲਝਾਇਆ ਲਾਂਚ ਪਾਥ, ਫਾਈਲ ਦਾ ਪੈਕੇਜ ਨਾਲ ਸਬੰਧ, ਰੈਪਰ ਦੀ ਥਾਂ ਅਤੇ ਉਹ ਬਦਲਾਅ-ਰਿਕਾਰਡ ਇਕੱਠਾ ਕਰੋ ਜਿਸ ਨੇ ਇਹ ਲਿਆਂਦਾ। ਜੇ ਰੈਪਰ ਵਿੱਚ ਬਾਅਦ ਵਿੱਚ ਲੋੜੀਂਦਾ ਏਕੀਕਰਣ ਕੰਮ ਹੈ ਤਾਂ ਇਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਥਾਂ ਉੱਤੇ ਨਕਲ ਕਰੋ।

ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਰੈਪਰ ਦੀ ਸਮੱਗਰੀ ਸਹਾਇਤਾ ਥ੍ਰੈਡ ਵਿੱਚ ਪੇਸਟ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਸਕ੍ਰਿਪਟਾਂ ਕਈ ਵਾਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਜਾਂ ਗੇਟਵੇ ਦੇ ਵੇਰਵੇ ਰੱਖਦੀਆਂ ਹਨ।

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

ਲਾਂਚ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਰੈਪਰ ਹਟਾਓ

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

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

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