OpenVPN ਕੋਈ ਗਲਤੀ ਦਿਖਾਏ ਬਿਨਾਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ? ਜਰਨਲ ਵੇਖੋ

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

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

ਚੁੱਪ ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਸਹੀ ਚੈਨਲ ਨਹੀਂ ਵੇਖ ਰਹੇ ਸੀ

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

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

ਸਾਫ਼ ਨਿਕਾਸ ਨੂੰ ਸਿਗਨਲ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਸ਼ਾਮਲ ਕਰੋ systemctl show -p Result -p ExecMainStatus openvpn-client@office। ਸਥਿਤੀ 1 ਅਤੇ Result=exit-code ਪ੍ਰੋਗਰਾਮ ਦਾ ਫੈਸਲਾ ਹੈ; Result=signal ਜਾਂ ਟਾਈਮਆਊਟ ਇਸਦੀ ਬਜਾਏ ਵਾਤਾਵਰਣ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਸੰਪਾਦਨ ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲੇਗੀ। ਕੁਝ ਵੀ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਮੁੱਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ ਉਹ ਅਸਥਾਈ ਸਥਿਤੀ ਮਿਟਾ ਦਿੰਦਾ ਹੈ ਜਿਸਨੇ ਉਹਨਾਂ ਨੂੰ ਪੈਦਾ ਕੀਤਾ।

ਇੰਸਟੈਂਸ ਦਾ ਨਾਮ ਪਾਥ ਦਾ ਹਿੱਸਾ ਹੈ

ਪੈਕੇਜ ਕੀਤੀ ਟੈਂਪਲੇਟ ਯੂਨਿਟ ਫਾਈਲ ਪਾਥ ਨਹੀਂ ਲੈਂਦੀ। ਇਹ ਇੰਸਟੈਂਸ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਲੱਭਣ ਲਈ ਉਹ ਨਾਮ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ: office Debian ਅਤੇ Ubuntu ਪੈਕੇਜਿੰਗ ਵਿੱਚ /etc/openvpn/client/office.conf ਵਜੋਂ ਹੱਲ ਹੁੰਦਾ ਹੈ। office-v2.conf ਨਾਮ ਦੀ ਫਾਈਲ @office ਵਜੋਂ ਸ਼ੁਰੂ ਕਰਨ ਤੇ ਵੀ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹੀ ਜਾਂਦੀ, ਅਤੇ ਯੂਨਿਟ ਚੁੱਪਚਾਪ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਸਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਸੀ। ਖੋਜ ਡਾਇਰੈਕਟਰੀ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਮੋਡ ਵਿੱਚ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਟੈਂਪਲੇਟ ਬਦਲਣ ਤੇ ਉਹੀ ਗਲਤੀ ਬਿਲਕੁਲ ਕਿਤੇ ਹੋਰ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।

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

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

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

ਜਦੋਂ ਪਲੱਗਇਨ ਸੁਰੰਗ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ, ਟਰਮੀਨਲ ਕੁਝ ਨਹੀਂ ਵੇਖਦਾ

ਡੈਸਕਟਾਪ ਐਪਲੈਟ ਤੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਕਨੈਕਸ਼ਨ NetworkManager ਦਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ OpenVPN ਆਉਟਪੁੱਟ ਤੁਹਾਡੇ ਖੋਲ੍ਹੇ ਕਿਸੇ ਸ਼ੈੱਲ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਉਸ ਸੇਵਾ ਦੇ ਜਰਨਲ ਵਿੱਚ ਜਾਂਦਾ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਹੱਥ ਨਾਲ ਚਲਾਉਣਾ ਅਤੇ ਕੁਝ ਨਾ ਦਿਖਣਾ ਉਸ ਵਿਵਸਥਾ ਵਿੱਚ ਆਮ ਹੈ, ਕਿਉਂਕਿ ਹੱਥ ਨਾਲ ਚਲਾਈ ਪ੍ਰਕਿਰਿਆ ਕਨੈਕਸ਼ਨ ਢੋਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ।

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

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

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

ਦੋ ਬਾਈਨਰੀ, ਇੱਕ PATH

ਹੱਥ ਨਾਲ ਬਣਾਈ ਇੰਸਟਾਲ ਜੋ /usr/local ਅਧੀਨ ਹੈ, ਸ਼ੈੱਲ ਕਾਲ ਵਿੱਚ ਜਿੱਤਦੀ ਹੈ, ਕਿਉਂਕਿ /usr/local/sbin ਡਿਫਾਲਟ Ubuntu PATH ਤੇ /usr/sbin ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ। ਯੂਨਿਟ ਤੁਹਾਡਾ PATH ਨਹੀਂ ਵਰਤਦੀ; ਇਹ ExecStart ਵਿੱਚ ਲਿਖਿਆ ਨਿਰਪੇਖ ਪਾਥ ਚਲਾਉਂਦੀ ਹੈ। ਇਸ ਲਈ ਤੁਹਾਡੇ ਟਰਮੀਨਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸੰਸਕਰਣ ਅਤੇ ਸੇਵਾ ਵਜੋਂ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਸੰਸਕਰਣ ਸੱਚਮੁੱਚ ਵੱਖਰੇ ਪ੍ਰੋਗਰਾਮ ਹੋ ਸਕਦੇ ਹਨ।

ਕੁਝ ਵੀ ਮੁੜ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਤੀਜੀ ਕਮਾਂਡ ਹੀ ਦਲੀਲ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ।

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

ਇੱਕ ਹੋਰ ਵਾਤਾਵਰਣਕ ਫਰਕ ਉਸੇ ਥਾਂ ਲੁਕਿਆ ਹੋਇਆ ਹੈ। ਪੈਕੇਜ ਕੀਤੀ ਯੂਨਿਟ /run ਅਧੀਨ systemd ਵੱਲੋਂ ਇਸ ਲਈ ਬਣਾਈ ਰਨਟਾਈਮ ਡਾਇਰੈਕਟਰੀ ਤੇ ਨਿਰਭਰ ਹੈ; ਉਹ ਸੈਟਿੰਗ ਛੱਡਣ ਵਾਲੀ ਹੱਥ ਨਾਲ ਲਿਖੀ ਬਦਲਵੀਂ ਯੂਨਿਟ ਇੱਕ ਵੀ ਫਾਈਲ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਅਸਫਲਤਾ ਕਿਸੇ OpenVPN ਸੁਨੇਹੇ ਬਿਨਾਂ ਆਮ ਇਨਕਾਰ ਵਰਗੀ ਦਿਖਦੀ ਹੈ।

ਉਹ ਅਸਫਲਤਾਵਾਂ ਜੋ ਕਲਾਇੰਟ ਦੱਸ ਨਹੀਂ ਸਕਦਾ

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

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

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