ਇੱਕ ਟਾਈਮਆਉਟ ਤੋਂ ਬਾਅਦ ਤੁਹਾਡਾ OpenVPN ਕਲਾਇੰਟ ਕਿਉਂ ਬੰਦ ਰਹਿੰਦਾ ਹੈ

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

ਯੂਨਿਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕੀਤਾ, ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਮੌਨੀਟਰਿੰਗ ਜੋ ਦਾਅਵਾ ਕਰਦੀ ਹੈ ਉੱਥੋਂ ਨਹੀਂ। systemctl status openvpn-client@office ਅਤੇ journalctl -u openvpn-client@office -n 50 ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਕਾਰਨ ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੀ ਆਖਰੀ ਲਾਈਨ ਦਿਖਾਉਂਦੇ ਹਨ।

ਕਿਸੇ ਦੇ ਧਿਆਨ ਵਿੱਚ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਬੰਦ ਹੋ ਗਈ

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

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

ping-exit ਅਤੇ ping-restart ਵਿਚਕਾਰ ਚੋਣ

ਆਪਣੇ ਆਪ ਠੀਕ ਹੋਣ ਵਾਲੇ ਲੈਪਟਾਪ ਜਾਂ ਦੂਰ ਦੀ ਸਾਈਟ ਲਈ ping-restart ਚੁਣੋ, ਅਤੇ ਮਰੇ ਟਨਲ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਰੋਕਣੀ ਪਵੇ ਤਾਂ ping-exit ਰੱਖੋ ਤਾਂ ਜੋ ਕੋਈ ਹੋਰ ਚੀਜ਼ ਇਸ 'ਤੇ ਕਾਰਵਾਈ ਕਰ ਸਕੇ। ਸੰਖਿਆਵਾਂ ਸੰਬੰਧ ਤੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਹਨ: ping 10 ਨਾਲ ping-restart 60 ਦਾ ਮਤਲਬ ਹੈ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਦਸ ਸਕਿੰਟ ਚੁੱਪ ਅਤੇ ਰੀਸਟਾਰਟ ਤੋਂ ਪਹਿਲਾਂ ਸੱਠ, ਜੋ ਨੁਕਸਾਨ ਵਾਲੇ ਮੋਬਾਈਲ ਲਿੰਕ 'ਤੇ ਹਮਲਾਵਰ ਅਤੇ ਤਾਰ ਵਾਲੇ 'ਤੇ ਵਾਜਬ ਹੈ। ਕਾਰਨ ਲਾਈਨ ਦੇ ਕੋਲ ਲਿਖੋ, ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਪਾਠਕ ਮੰਨ ਲਵੇਗਾ ਕਿ ਡਿਫਾਲਟ ਮੁੱਲ ਜਾਣ-ਬੁੱਝ ਕੇ ਰੱਖੇ ਗਏ ਸਨ।

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

ਯੂਨਿਟ ਨੂੰ ਸੱਚਮੁੱਚ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੀ ਨਿਗਰਾਨੀ

systemd ਹੋਸਟ 'ਤੇ ਸਭ ਤੋਂ ਛੋਟਾ ਟਿਕਾਊ ਬਦਲਾਅ ਇੱਕ drop-in ਫਾਈਲ ਹੈ: Restart=on-failure ਅਤੇ RestartSec=10, ਜੋ /etc/systemd/system/[email protected]/restart.conf ਵਿੱਚ ਹਨ। drop-in ਤਦ ਹੀ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ systemd ਆਪਣੀਆਂ ਪਰਿਭਾਸ਼ਾਵਾਂ ਮੁੜ ਲੋਡ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਉਸ ਮਗਰੋਂ systemctl daemon-reload ਚਲਾਓ। ਮੁੱਲ ਪਹੁੰਚ ਗਿਆ ਮੰਨਣ ਦੀ ਥਾਂ systemctl show -p Restart -p ExecMainStatus openvpn-client@office ਨਾਲ ਜਾਂਚੋ। ਫਾਈਲ ਨਾਂ ਦਾ ਇੰਸਟੈਂਸ ਉਹੀ ਪ੍ਰੋਫਾਈਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਯੂਨਿਟ ਅਸਲ ਵਿੱਚ ਲੋਡ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ office ਲਈ ਲਿਖੀ ਫਾਈਲ openvpn-client@home ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦੀ।

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

Restart=always ਜਾਣ-ਬੁੱਝ ਕੇ ਰੋਕਣ ਮਗਰੋਂ ਵੀ ਸਰਗਰਮ ਹੁੰਦਾ ਹੈ। ਸੰਭਾਲ ਲਈ systemctl stop ਵਰਤੋ, ਅਤੇ ਜੇ ਕੰਮ ਕਰਦਿਆਂ ਯੂਨਿਟ ਬੰਦ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਇਸ ਨੂੰ ਮਾਸਕ ਕਰੋ।

ਟਨਲ ਬੰਦ ਹੋਣ ਵੇਲੇ ਲੀਕ ਫੜੋ

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

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

ਕਲਾਇੰਟ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਰੋਕ ਕੇ ਇਹ ਪਰਖੋ। systemctl stop openvpn-client@office ਚਲਾਓ, ਫਿਰ curl -m 5 https://example.com, ਜੋ ਭੌਤਿਕ ਲਿੰਕ 'ਤੇ ਸਫਲ ਹੋਣ ਦੀ ਥਾਂ ਫੇਲ੍ਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਫਲਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫਾਇਰਵਾਲ ਨਿਯਮ ਗਾਇਬ ਹੈ ਜਾਂ ਬਹੁਤ ਵੱਧ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਹੈ।

ਮੁੜ ਜੁੜੋ, ਟਨਲ ਫਿਰ ਟ੍ਰੈਫਿਕ ਢੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਫਿਰ ਹੀ ਜਾਂਚ ਮੌਨੀਟਰਿੰਗ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ। cron ਤੋਂ ip addr ਨਾਲ tun ਡਿਵਾਈਸ ਲਈ ਪੁੱਛਗਿੱਛ ਕਰਨਾ ਸਭ ਤੋਂ ਵੱਧ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਨਿਗਰਾਨੀ ਹੈ, ਕਿਉਂਕਿ persist-tun ਨਾਲ ਡਿਵਾਈਸ ਸੈਸ਼ਨ ਤੋਂ ਵੱਧ ਜੀਵਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਨਾ ਢੋਏ ਜਾਣ ਵੇਲੇ ਵੀ ਜਾਂਚ ਸਿਹਤਮੰਦ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਦਿੰਦੀ ਹੈ।