ਹਰ ਘੰਟੇ OpenVPN ਡਰਾਪ: ਮੁੜ ਗੱਲਬਾਤ ਜਾਂ ਸੱਚੀ ਮੁੜ-ਜੁੜਾਈ?

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

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

ਨਰਮ ਰੀਸੈਟ ਨੂੰ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਤੋਂ ਵੱਖ ਪਛਾਣੋ

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

ਲਾਗੂ ਟਾਈਮਰ ਪੜ੍ਹੋ, ਆਪਣੀ ਫਾਈਲ ਨਹੀਂ

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

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

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

ਇਸ ਨੂੰ ਉੱਥੇ ਬਦਲੋ ਜਿੱਥੇ ਇਹ ਅਸਲ ਵਿੱਚ ਪੁਸ਼ ਹੁੰਦਾ ਹੈ

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

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

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

ਮੁੜ ਗੱਲਬਾਤ ਬੰਦ ਕਰਕੇ ਤੁਸੀਂ ਕੀ ਛੱਡਦੇ ਹੋ

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

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

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

ਜਦੋਂ ਅੰਤਰਾਲ ਕਿਤੇ ਹੋਰ ਇਸ਼ਾਰਾ ਕਰੇ

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

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

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