TLS ਗਲਤੀ ਤੋਂ ਬਾਅਦ OpenVPN ਵਾਰ-ਵਾਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ: ਇਸਨੂੰ ਕਿਵੇਂ ਰੋਕੀਏ

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

ਪਹਿਲੀ ਗਲਤੀ ਲੁਕਾਉਣ ਵਾਲਾ ਚੱਕਰ

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

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

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪੂਰਾ ਚੱਕਰ ਰਿਕਾਰਡ ਕਰੋ। ਦੂਰ ਦਾ ਪਤਾ, ਗਲਤੀ ਵਿੱਚ ਦੱਸਿਆ TLS ਪੜਾਅ ਅਤੇ ਕੀ ਪ੍ਰਕਿਰਿਆ ਬਿਲਕੁਲ ਬਾਹਰ ਨਿਕਲਦੀ ਹੈ, ਲਿਖੋ।

ਲੂਪ ਪਿੱਛੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਦੀ ਮਸ਼ੀਨਰੀ

ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਡਿਫਾਲਟ ਹੈ ਕਿਉਂਕਿ ਕਈ ਅਸੰਬੰਧਿਤ ਟਾਈਮਆਉਟ ਇੱਕੋ ਮਸ਼ੀਨਰੀ ਸਾਂਝੀ ਕਰਦੇ ਹਨ। connect-retry ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿਚਕਾਰ ਅੰਤਰਾਲ ਤੈਅ ਕਰਦਾ ਹੈ, connect-retry-max ਹਰ ਦੂਰ ਦੀ ਐਂਟਰੀ ਕਿੰਨੀ ਵਾਰ ਅਜ਼ਮਾਈ ਜਾਵੇ ਸੀਮਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ resolv-retry ਦੁਹਰਾਏ ਨਾਮ ਖੋਜ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ। TLS ਗੱਲਬਾਤ ਅਸਫਲਤਾ ਆਵਾਜਾਈ ਘਟਨਾ ਵਜੋਂ ਉਸ ਮਸ਼ੀਨਰੀ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਰਿਪੋਰਟ ਕਰਨ ਦੀ ਥਾਂ ਇੱਕ ਹੋਰ ਕੋਸ਼ਿਸ਼ ਤੈਅ ਕਰਦਾ ਹੈ। ਡਿਫਾਲਟ ਮੁੱਲ ਅਸਥਿਰ ਲਿੰਕ ਲਈ ਲਾਹੇਵੰਦ ਅਤੇ ਉਸ ਨੁਕਸ ਲਈ ਨੁਕਸਾਨਦੇਹ ਹੈ ਜੋ ਠੀਕ ਨਹੀਂ ਹੋ ਸਕਦਾ।

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

TLS ਅਸਫਲਤਾ ਤੇ ਕਲਾਇੰਟ ਨੂੰ ਬਾਹਰ ਨਿਕਲਣ ਦੇਣਾ

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

ਉਹ ਨਿਕਾਸ ਦਿਖਣਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ, ਸੁਪਰਵਾਈਜ਼ਰ ਤੈਅ ਕਰਦਾ ਹੈ। Restart=always ਜਾਂ Restart=on-failure ਵਾਲਾ systemd ਯੂਨਿਟ ਕਲਾਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਲੂਪ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਵਿਕਲਪ ਕੁਝ ਨਾ ਕਰਦਾ ਜਾਪਦਾ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀ ਜਾਂਚੋ:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

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

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

ਇੱਕ ਵਾਰੀ ਵਰਤੋਂ ਵਾਲੇ ਐਂਡਪੌਇੰਟ ਨਾਲ ਸਾਬਤ ਕਰੋ

ਵਿਵਹਾਰ ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਦੇਖਣ ਲਈ, ਪ੍ਰੋਫਾਈਲ ਦੀ ਨਕਲ ਕਰੋ ਅਤੇ ਨਕਲ ਨੂੰ ਅਜਿਹੇ ਐਂਡਪੌਇੰਟ ਵੱਲ ਸੇਧਿਤ ਕਰੋ ਜੋ TCP ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਪਰ ਕਦੇ OpenVPN ਨਹੀਂ ਬੋਲਦਾ। ਜਵਾਬ ਦੇ ਕੇ ਫਿਰ ਚੁੱਪ ਰਹਿਣ ਵਾਲਾ ਸਰੋਤਾ ਕਾਫ਼ੀ ਹੈ। tls-exit ਨਾਲ, ਹੈਂਡਸ਼ੇਕ ਅਸਫਲ ਹੋਣ ਤੇ ਕਲਾਇੰਟ ਖਤਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਇਸ ਤੋਂ ਬਿਨਾਂ ਉਹੀ ਪ੍ਰੋਫਾਈਲ ਘੁੰਮਦਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਨਕਲ ਵਰਤੋ, ਕਦੇ ਕੰਮ ਕਰ ਰਿਹਾ ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ।

ਦੋਵੇਂ ਰਨ ਨਿਕਾਸ ਸਥਿਤੀ ਅਤੇ ਪਹਿਲੀ ਗਲਤੀ ਲਾਈਨ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਇਸ ਨਾਲ ਨਹੀਂ ਕਿ ਹਰ ਇੱਕ ਕਿੰਨੀ ਦੇਰ ਚੱਲਿਆ। ਸਥਿਤੀ ਦੱਸਦੀ ਹੈ ਕਿ ਵਿਕਲਪ ਚੱਲਿਆ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਪਹਿਲੀ ਲਾਈਨ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਪੜਾਅ ਅਸਫਲ ਹੋਇਆ।

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

ਉਹ ਪੜਾਅ ਜਿੱਥੇ ਇਹ ਵਿਕਲਪ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ

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

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

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