OpenVPN active (exited) ਕਹਿੰਦਾ ਹੈ? ਜੋ ਇੰਸਟੈਂਸ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਉਹ ਲੱਭੋ

ਤੁਸੀਂ ਟਨਲ ਜਾਂਚਦੇ ਹੋ, systemctl status openvpn ਚਲਾਉਂਦੇ ਹੋ ਅਤੇ Main PID ਤੋਂ ਬਿਨਾਂ ਤੇ ਖਾਲੀ ਪ੍ਰੋਸੈਸ ਸੂਚੀ ਨਾਲ active (exited) ਮਿਲਦਾ ਹੈ। ਸੇਵਾ ਸ਼ੁਰੂ ਹੋ ਕੇ ਮਰ ਗਈ ਇਹ ਸੁਭਾਵਿਕ ਪਾਠ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ unit ਖੋਲ੍ਹਦੇ ਹੋ, /bin/true ਲੱਭਦੇ ਹੋ ਅਤੇ ਪੈਕੇਜ ਟੁੱਟਾ ਹੈ ਅਜਿਹਾ ਸਿੱਟਾ ਕੱਢਦੇ ਹੋ। Debian ਪੈਕੇਜਿੰਗ ਵਿੱਚ ਉਹ ਅਵਸਥਾ ਡਿਜ਼ਾਈਨ ਮੁਤਾਬਕ ਕੰਮ ਕਰਦਾ wrapper ਹੈ, ਅਤੇ ਟਨਲ ਉਸ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤੇ instance unit ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। ਸਮੁੱਚਾ unit ਕਦੇ ਨਹੀਂ ਦੱਸੇਗਾ ਕਿ ਕਿਹੜੇ ਇੰਸਟੈਂਸ ਨੇ ਇਸਨੂੰ ਬਣਾਇਆ।

ਇਸ unit ਉੱਤੇ active (exited) ਦਾ ਅਸਲ ਅਰਥ ਕੀ ਹੈ

ਪੈਕੇਜ ਕੀਤਾ unit ਇੱਕ-ਵਾਰ ਦਾ ਕੰਮ ਹੈ: ਇਸਦਾ ExecStart /bin/true ਹੈ, ਅਤੇ ਪੂਰਾ ਹੋਇਆ unit active (exited) ਵਜੋਂ ਰਿਪੋਰਟ ਹੁੰਦਾ ਰਹੇ ਇਸਦਾ ਕਾਰਨ RemainAfterExit=yes ਹੈ। ਉਹ ਨਿਰਦੇਸ਼ ਹਟਾਓ ਤਾਂ ਉਹੀ ਸਫਲ /bin/true ਕੰਮ inactive (dead) ਵਿੱਚ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ, ਜੋ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਅਤੇ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਗ਼ਲਤ ਪੜ੍ਹਤ ਦੀ ਠੀਕ ਉਹੀ ਅਵਸਥਾ ਹੈ। ਕਮਾਂਡ ਸਿਰਫ਼ ਥਾਂ ਭਰਨ ਵਾਲੀ ਹੈ, ਅਤੇ unit ਹੋਰ unit ਵੱਲੋਂ ਕੀਤੇ ਕੰਮ ਦੀ ਰਿਪੋਰਟ ਦਿੰਦਾ ਹੈ। ਇਸ ਬੰਦੋਬਸਤ ਵਿੱਚ ਕੁਝ ਵੀ ਟੁੱਟਾ ਨਹੀਂ, ਅਤੇ /bin/true ਬਦਲਣਾ ਟਨਲ ਨਹੀਂ ਸਗੋਂ ਪੈਕੇਜਿੰਗ ਸਮਝੌਤਾ ਬਦਲਦਾ ਹੈ।

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

ਬਰੈਕਟ ਵਿੱਚਲੇ ਸ਼ਬਦ ਦੀ ਥਾਂ status ਆਉਟਪੁੱਟ ਦੀਆਂ ਤਿੰਨ ਲਾਈਨਾਂ ਪੜ੍ਹੋ। Loaded systemd ਵੱਲੋਂ ਪੜ੍ਹੀ unit ਫਾਈਲ ਦਾ ਨਾਂ ਦਿੰਦਾ ਹੈ, Active ਆਖਰੀ ਸਫਲ ਦੌੜ ਦਾ ਸਮਾਂ-ਛਾਪ ਰੱਖਦਾ ਹੈ, ਅਤੇ Main PID ਦਾ ਨਾ ਹੋਣਾ ਪੂਰੇ ਹੋਏ ਇੱਕ-ਵਾਰ ਦੇ ਕੰਮ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਉਹ ਤਿੰਨ ਲਾਈਨਾਂ ਹੀ ਇਸ wrapper ਨੂੰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਇੱਕ ਸਕਿੰਟ ਬਾਅਦ ਡਿੱਗੀ ਸੇਵਾ ਤੋਂ ਵੱਖ ਪਛਾਣਨ ਦਾ ਤਰੀਕਾ ਹਨ।

status ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ unitਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ

ਕੀ ਚੱਲ ਰਿਹਾ ਹੈ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ systemd ਨੂੰ ਪੁੱਛੋ ਕਿ ਕੀ ਮੌਜੂਦ ਹੈ। ਕੋਈ ਇੰਸਟੈਂਸ ਬਣਾਏ ਬਿਨਾਂ ਟੈਂਪਲੇਟ ਸਥਾਪਿਤ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਬਣਿਆ unit ਹੀ ਟਨਲ ਰੱਖਦਾ ਹੈ। ਲੋਡ ਹੋਏ ਸੈੱਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:

systemctl list-units 'openvpn*'

ਉਹ ਸੂਚੀ ਉਹੀ ਹੈ ਜੋ systemd ਨੇ ਇਸ ਪਲ ਲੋਡ ਕੀਤਾ, ਅਤੇ ਇਹ ਟਨਲ ਸੂਚੀ ਦੇ ਸਭ ਤੋਂ ਨੇੜੇ ਹੈ। ਸਥਾਪਿਤ unit ਫਾਈਲਾਂ ਦੂਜੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਕੁਝ ਨਾ ਬਣੇ ਹੋਣ ’ਤੇ ਵੀ ਉਹ ਸੂਚੀ ਟੈਂਪਲੇਟ ਦਿਖਾਉਂਦੀ ਹੈ:

systemctl list-unit-files 'openvpn*'

ਦੋਵੇਂ ਸੂਚੀਆਂ ਇਕੱਠੀਆਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਦੂਜੀ ਵਿੱਚ ਟੈਂਪਲੇਟ ਅਤੇ ਪਹਿਲੀ ਵਿੱਚ ਇੰਸਟੈਂਸ ਦੋ ਵੱਖ ਜਵਾਬ ਹਨ। ਮੌਜੂਦ ਟੈਂਪਲੇਟ ਅਤੇ ਚੱਲਦਾ ਇੰਸਟੈਂਸ ਇੱਕੋ ਤੱਥ ਨਹੀਂ, ਅਤੇ ਸਿਰਫ਼ ਦੂਜਾ ਹੀ ਟਨਲ ਦਾ ਅਰਥ ਦਿੰਦਾ ਹੈ। ਪੈਕੇਜ ਖਾਕੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨਾਂ ਅਤੇ OpenVPN ਵਰਜਨਾਂ ਵਿੱਚ ਵੀ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਪੁਰਾਣਾ openvpn@ ਟੈਂਪਲੇਟ, ਵੱਖਰੀ client ਅਤੇ server ਜੋੜੀ, ਅਤੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ wrapper ਆਪੋ-ਆਪਣੀ ਪੈਕੇਜਿੰਗ ਵਿੱਚ ਜਾਇਜ਼ ਹੋ ਸਕਦੇ ਹਨ।

ਆਪਣੀ ਮਸ਼ੀਨ ਮੁਤਾਬਕ ਢਲੋ, ਨਾ ਕਿ ਮਿਲੀ ਟਿਊਟੋਰੀਅਲ ਮੁਤਾਬਕ। ਕਿਸੇ ਹੋਰ ਦੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਇੰਸਟੈਂਸ ਦਾ ਨਾਂ office ਹੋ ਸਕਦਾ ਹੈ ਜਦਕਿ ਤੁਹਾਡਾ home ਜਾਂ work ਹੈ। ਜੋ ਅੱਗੇ ਲੰਘਦਾ ਹੈ ਉਹ ਢੰਗ ਹੈ, ਸਟਰਿੰਗ ਨਹੀਂ।

ਇੰਸਟੈਂਸ ਦੇ ਨਾਂ ਤੋਂ ਉਸ ਫਾਈਲ ਤੱਕ ਜਾਓ ਜੋ ਇਹ ਪੜ੍ਹਦਾ ਹੈ

upstream client ਟੈਂਪਲੇਟ ਵਿੱਚ unit ਦੀ ਕਾਰਜ ਡਾਇਰੈਕਟਰੀ /etc/openvpn/client ਹੈ ਅਤੇ ਇਸਦੀ ਕਮਾਂਡ ਉੱਥੋਂ %i.conf ਲੈਂਦੀ ਹੈ, ਇਸ ਲਈ openvpn-client@office /etc/openvpn/client/office.conf ਪੜ੍ਹਦਾ ਹੈ। ਉਦਾਹਰਨ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਸਥਾਪਿਤ unit ਉੱਤੇ ਉਹ ਮੈਪਿੰਗ ਪੱਕੀ ਕਰੋ, ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਟੈਂਪਲੇਟ ਪੁਰਾਣਾ ਜਾਂ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਵੱਲੋਂ ਮੁੜ-ਲਿਖਿਆ ਹੋ ਸਕਦਾ ਹੈ:

systemctl cat [email protected]

ਉਸ ਆਉਟਪੁੱਟ ਦੇ ਹੇਠਾਂ ਦਿਸਦੇ drop-in ਪੜ੍ਹੋ, ਕਿਉਂਕਿ .d/ ਹੇਠਲੀ ਫਾਈਲ ExecStart, ਕਾਰਜ ਡਾਇਰੈਕਟਰੀ ਜਾਂ ਸੰਰਚਨਾ ਮਾਰਗ ਬਦਲ ਸਕਦੀ ਹੈ। ਤੁਸੀਂ office.ovpn ਵਜੋਂ ਡਾਊਨਲੋਡ ਕੀਤਾ ਪ੍ਰੋਫਾਈਲ ਇੰਸਟੈਂਸ ਵੱਲੋਂ ਖੋਲ੍ਹੀ ਫਾਈਲ ਨਹੀਂ ਹੈ। ਇਹੀ ਅੰਤਰ ਆਮ ਤੌਰ ’ਤੇ ਕਾਰਨ ਹੁੰਦਾ ਹੈ ਕਿ ਗ਼ਲਤੀ ਉਹ ਮਾਰਗ ਦੱਸਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਸੰਪਾਦਿਤ ਨਹੀਂ ਕੀਤਾ।

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

ਇਸਨੂੰ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਉਸ ਇੰਸਟੈਂਸ ਦਾ ਜਰਨਲ ਪੜ੍ਹੋ

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

sudo systemctl start [email protected]
journalctl -u [email protected] -b

ਸ਼ੁਰੂ ਕਰਨਾ ਅਤੇ ਸਮਰੱਥ ਕਰਨਾ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਹਨ: start unit ਹੁਣ ਚਲਾਉਂਦਾ ਹੈ, enable ਅਗਲੇ ਬੂਟ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ, ਅਤੇ enable --now ਦੋਵੇਂ ਇੱਕ ਕਦਮ ਵਿੱਚ ਕਰਦਾ ਹੈ। daemon-reload unit ਪਰਿਭਾਸ਼ਾਵਾਂ ਮੁੜ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਮੁੜ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ ਜਾਂ ਸੰਪਾਦਿਤ ਪ੍ਰੋਫਾਈਲ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ। ਪ੍ਰੋਫਾਈਲ ਬਦਲਣ ਮਗਰੋਂ ਇੰਸਟੈਂਸ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਫਾਈਲ ਮੁੜ ਪੜ੍ਹਨ ਵਾਲਾ ਉਹੀ ਹੈ।

ਇੱਕੋ ਟਨਲ ’ਤੇ ਦੂਜਾ ਮੈਨੇਜਰ ਨਾ ਰੱਖੋ

NetworkManager ਅਤੇ OpenVPN 3 ਸੈਸ਼ਨ ਮੈਨੇਜਰਾਂ ਦੀ ਆਪਣੀ ਕਨੈਕਸ਼ਨ ਅਵਸਥਾ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੇ ਕੋਲ systemd ਇੰਸਟੈਂਸ ਰੱਖਣਾ ਉਸੇ ਟਨਲ ’ਤੇ ਦੋ ਮਾਲਕ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਲੱਛਣ ਇਹ ਹੈ ਕਿ ਟਨਲ ਉੱਪਰ ਆਉਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਰੁਕਿਆ ਰਹਿਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਡੈਸਕਟਾਪ ਲਈ ਜਿਸ ਮੈਨੇਜਰ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਉਹ ਚੁਣੋ, ਅਤੇ ਸਰਵਰ ’ਤੇ systemd ਜਾਣ-ਬੁੱਝ ਕੇ ਵਰਤੋ।

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

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