VPN ਯੂਨਿਟ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹਿਲਾਂ ਕਿਉਂ ਸ਼ੁਰੂ ਹੋ ਕੇ ਫਿਰ ਮਰ ਜਾਂਦਾ ਹੈ

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

ਟਾਰਗਿਟ ਮਿਲਣ ਦੀ ਥਾਂ ਹੈ, ਪ੍ਰਬੰਧਕ ਨਹੀਂ

network-online.target ਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ ਨੈੱਟਵਰਕ ਕੀ ਹੈ। ਇਹ ਇੱਕ ਤਾਲਮੇਲ ਬਿੰਦੂ ਹੈ ਜੋ ਉਸ ਸੇਵਾ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਲਿੰਕ ਵਰਤੋਂਯੋਗ ਹੋਣ ਤੱਕ ਸ਼ੁਰੂਆਤ ਦੇਰੀ ਨਾਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਉਸ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਨੂੰ ਸੌਂਪਦਾ ਹੈ ਜੋ ਮਸ਼ੀਨ ਦਾ ਮਾਲਕ ਹੈ। ਬਹੁਤੇ ਡੈਸਕਟਾਪ ਅਤੇ ਸਰਵਰਾਂ 'ਤੇ ਇਸ ਦਾ ਅਰਥ NetworkManager ਜਾਂ systemd-networkd ਵੱਲੋਂ ਦਿੱਤੀ ਜਾਂਦੀ ਉਡੀਕ-ਸੇਵਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਸਰਗਰਮ ਨਾ ਕਰੋ ਤਾਂ ਟਾਰਗਿਟ ਕੋਲ ਉਡੀਕਣ ਲਈ ਕੁਝ ਨਹੀਂ ਰਹਿੰਦਾ, ਇਸ ਲਈ ਜਿਸ ਪਲ ਕੋਈ ਚੀਜ਼ ਇਸ ਨੂੰ ਖਿੱਚਦੀ ਹੈ ਉਸੇ ਪਲ ਇਹ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ DHCP ਦੇ ਜਵਾਬ ਦੇਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਹੋ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੇ ਯੂਨਿਟ ਦੀ ਕ੍ਰਮ-ਲਾਈਨ ਇਮਾਨਦਾਰ ਸੀ ਅਤੇ ਫਿਰ ਵੀ ਬੇਕਾਰ।

ਇਸ ਲਈ ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਤੁਹਾਡਾ ਯੂਨਿਟ ਕੀ ਐਲਾਨਦਾ ਹੈ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇਸ ਮਸ਼ੀਨ 'ਤੇ ਸੱਚਮੁੱਚ ਕੁਝ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਯੂਨਿਟ ਫਾਈਲ ਦੀ ਬਜਾਏ ਆਖਰੀ ਬੂਟ ਪੜ੍ਹੋ

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

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

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

ਉਡੀਕ ਜੋੜੋ, ਫਿਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼

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

OpenVPN ਕਲਾਇੰਟ ਦਾ ਪੈਕੇਜ ਕੀਤਾ ਯੂਨਿਟ ਪਹਿਲਾਂ ਹੀ ਦੋਵੇਂ ਰੱਖਦਾ ਹੈ। ਹੱਥ ਨਾਲ ਲਿਖੇ ਯੂਨਿਟ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਜਾਂ ਕੋਈ ਨਹੀਂ ਰੱਖਦੇ, ਜੋ ਕੁਝ ਵੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਣ ਯੋਗ ਹੈ।

[Service]
Restart=on-failure
RestartSec=15

ਨਿਸ਼ਚਿਤ ਨੀਂਦ ਇੱਕ ਜਾਲ ਕਿਉਂ ਹੈ

ExecStartPre ਵਿੱਚ ਨੀਂਦ ਕ੍ਰਮ-ਸੁਧਾਰ ਵਾਂਗ ਲੱਗਦੀ ਹੈ ਅਤੇ ਵਾਧੂ ਕਦਮਾਂ ਵਾਲੀ ਦੇਰੀ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਇਹ ਹਰ ਬੂਟ ਨੂੰ ਹੌਲੀ ਕਰਦੀ ਹੈ, ਉਹ ਵੀ ਜੋ ਸਿਹਤਮੰਦ ਸਨ, ਅਤੇ ਤੁਹਾਡੇ ਚੁਣੇ ਨੰਬਰ ਨਾਲੋਂ ਲਿੰਕ ਵੱਧ ਸਮਾਂ ਲੈਣ 'ਤੇ ਵੀ ਹਾਰਦੀ ਹੈ।

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

ਜਦੋਂ ਕ੍ਰਮ ਸਹੀ ਹੋਵੇ ਅਤੇ ਨਾਮ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਣ

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

ਜੇ ਮੁੜ-ਸ਼ੁਰੂ ਖੋਜਾਂ ਠੀਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਗਲਤ DNS ਸਰਵਰ ਨਹੀਂ ਸਗੋਂ ਸ਼ੁਰੂਆਤੀ ਕ੍ਰਮ ਦੀ ਖਾਮੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੋਵਾਂ ਲਈ ਵੱਖਰੇ ਸੁਧਾਰ ਚਾਹੀਦੇ ਹਨ। ਫਿਰ ਪੂਰੀ ਗੱਲ ਸੇਵਾ ਮੁੜ-ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਠੰਢੇ ਬੂਟ ਨਾਲ ਸਾਬਤ ਕਰੋ, ਕਿਉਂਕਿ ਮੁੜ-ਸ਼ੁਰੂ ਪਹਿਲਾਂ ਹੀ ਉੱਪਰ ਚੱਲ ਰਹੇ ਨੈੱਟਵਰਕ ਦੇ ਵਿਰੁੱਧ ਚੱਲਦਾ ਹੈ ਅਤੇ ਠੀਕ ਉਹੀ ਖਾਮੀ ਲੁਕਾਏਗਾ ਜਿਸ ਦਾ ਤੁਸੀਂ ਪਿੱਛਾ ਕਰ ਰਹੇ ਹੋ। ਲਿੰਕ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੌਲੀ ਰੱਖ ਕੇ ਇਸ ਨੂੰ ਦੁਹਰਾਓ, ਅਤੇ ਜੋ ਯੂਨਿਟ ਸਿਰਫ਼ ਤੇਜ਼ ਨੈੱਟਵਰਕ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਅਜੇ ਵੀ ਟੁੱਟਿਆ ਮੰਨੋ।