OpenVPN: ਬੂਟ ਵੇਲੇ ਸਥਾਨਕ ਬਾਈਂਡ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ — ਉਡੀਕ ਕਰੀਏ ਜਾਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼

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

ਦੋਵੇਂ ਇੱਕ ਸਥਿਰ ਨੀਂਦ ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ, ਜੋ ਨਾ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ ਅਤੇ ਨਾ ਹੀ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਸ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਸੀ।

local ਵਿਕਲਪ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗਦਾ ਹੈ

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

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

ਪਤੇ ਦੀ ਉਡੀਕ ਜਾਂ ਬਾਈਂਡ ਦੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼

ਉਡੀਕ ਦਾ ਮਤਲਬ ਹੈ ExecStartPre ਜੋ ਪਤਾ ਦਿਖਣ ਤੱਕ ਪੁੱਛਦਾ ਹੈ, ਸੀਮਿਤ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਸਮਾਂ ਖਤਮ ਹੋਣ 'ਤੇ ਗੈਰ-ਸਿਫ਼ਰ ਐਗਜ਼ਿਟ ਨਾਲ। ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਦਾ ਮਤਲਬ ਹੈ ਮੁੱਖ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਫੇਲ੍ਹ ਹੋਣ ਦੇਣਾ ਅਤੇ ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਨੂੰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਕਹਿਣਾ, ਉਦਾਹਰਨ ਲਈ Restart=on-failure ਨਾਲ RestartSec=5। ਪਹਿਲਾ ਗੁੰਮ ਪੂਰਵ ਸ਼ਰਤ ਨੂੰ ਫੇਲ੍ਹ ਯੂਨਿਟ ਵਜੋਂ ਦੱਸਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਦੂਜਾ ਇਸਨੂੰ ਰੀਸਟਾਰਟਾਂ ਦੀ ਲੜੀ ਵਜੋਂ ਦੱਸਦਾ ਹੈ ਜੋ ਅਖੀਰ ਰੁਕ ਜਾਂਦੀ ਹੈ; ਇਹ ਜਰਨਲ ਵਿੱਚ ਵਧੇਰੇ ਸ਼ੋਰ ਹੈ ਪਰ ਉਸ ਪਤੇ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਅੰਦਾਜ਼ੇ ਤੋਂ ਬਾਹਰ ਦੇ ਕਾਰਨਾਂ ਕਰਕੇ ਦੇਰ ਨਾਲ ਆਉਂਦਾ ਹੈ।

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

network-online.target ਕਿਉਂ ਕਾਫ਼ੀ ਨਹੀਂ

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

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

ਠੰਢੇ ਬੂਟ ਤੋਂ ਬਾਅਦ ਬਾਈਂਡਿੰਗ ਜਾਂਚੋ

ਸੇਵਾ ਰੀਸਟਾਰਟ ਦੀ ਥਾਂ ਅਸਲ ਠੰਢੇ ਬੂਟ ਨਾਲ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਰੀਸਟਾਰਟ ਉਹ ਪਤਾ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ ਜੋ ਬੂਟ ਕ੍ਰਮ ਨੂੰ ਬਣਾਉਣਾ ਪੈਂਦਾ ਸੀ। ਬੂਟ ਤੋਂ ਬਾਅਦ ss -lntp ਜਾਂ ss -lunp ਦੱਸਦਾ ਹੈ ਕਿ ਹਰ ਸਰੋਤਾ ਅਸਲ ਵਿੱਚ ਕਿਸ ਸਥਾਨਕ ਪਤੇ 'ਤੇ ਬਾਈਂਡ ਹੋਇਆ, ਅਤੇ journalctl -b -u openvpn-server@server ਦੱਸਦਾ ਹੈ ਕਿ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਫੇਲ੍ਹ ਹੋਈ ਜਾਂ ਨਹੀਂ। ਬਾਈਂਡ ਹੋਏ ਪਤੇ ਦੀ ਪ੍ਰੋਫਾਈਲ ਵਾਲੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਨੈੱਟਵਰਕ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਤੁਲਨਾ ਦੁਹਰਾਓ।

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

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