ਤੁਹਾਡਾ VPN ਬੰਦ ਹੋਣ ਨਾਲੋਂ ਵੱਧ ਸਮਾਂ ਕਿਉਂ ਲੈਂਦਾ ਹੈ ਠੀਕ ਹੋਣ ਵਿੱਚ
ਬੈਕਆਫ਼ ਮੁੜ ਜੁੜਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਵਿੱਚ ਵਿਰਾਮ ਪਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਮੁੜ-ਪ੍ਰਾਪਤ ਨੈੱਟਵਰਕ ਨੂੰ ਉਡੀਕ ਕਰਨੀ ਪੈ ਸਕਦੀ ਹੈ। ਟਾਈਮਰ ਘਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਦੇ ਸ਼ਡਿਊਲ ਦੀ ਨੈੱਟਵਰਕ ਦੀ ਤਿਆਰੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
Wi-Fi ਤੀਹ ਸਕਿੰਟ ਪਹਿਲਾਂ ਵਾਪਸ ਆਇਆ ਅਤੇ VPN ਅਜੇ ਵੀ ਬੰਦ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਟੁੱਟਿਆ ਲੱਗਦਾ ਹੈ। ਅਕਸਰ ਇਹ ਸਿਰਫ਼ ਆਪਣੇ ਹੀ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਸ਼ਡਿਊਲ ਦੀ ਪਾਲਣਾ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸ ਸ਼ਡਿਊਲ ਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ ਨੈੱਟਵਰਕ ਹੁਣੇ ਵਾਪਸ ਆਇਆ ਹੈ। ਉਹੀ ਫ਼ਰਕ ਪੂਰੀ ਕਹਾਣੀ ਹੈ: ਰਿਕਵਰੀ ਦਾ ਸਮਾਂ ਬੰਦ ਹੋਣਾ ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤੀ ਕੋਈ ਵੀ ਉਡੀਕ ਦਾ ਜੋੜ ਹੈ। ਹਰ ਟਾਈਮਰ ਘਟਾਉਣਾ ਇੱਕ ਜਵਾਬ ਹੈ, ਅਤੇ ਇਹ ਸਮਝਣਾ ਕਿ ਕਿਹੜਾ ਟਾਈਮਰ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ ਦੂਜਾ।
ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਟਿਊਨਿੰਗ ਮਦਦ ਕਰੇਗੀ ਜਾਂ ਨਹੀਂ: ਕਿਹੜਾ ਪੜਾਅ ਹੌਲੀ ਹੈ, ਕੀ ਅਸਫਲਤਾ ਬਿਲਕੁਲ ਵੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਯੋਗ ਹੈ, ਅਤੇ ਨੈੱਟਵਰਕ ਵਾਪਸ ਆਉਣ ਦਾ ਪਤਾ ਕਲਾਇੰਟ ਨੂੰ ਕਿਵੇਂ ਲੱਗਦਾ ਹੈ।
ਇੱਕੋ ਜਿਹੇ ਲੱਗਦੇ ਤਿੰਨ ਇੰਤਜ਼ਾਰ
ਐਂਡਪੌਇੰਟ ਰਿਜ਼ੋਲਿਊਸ਼ਨ, IKE ਜਾਂ TLS ਗੱਲਬਾਤ, ਪੈਕਟ ਮੁੜ-ਭੇਜਣਾ ਅਤੇ ਨਵੀਂ ਕੋਸ਼ਿਸ਼ ਸ਼ੁਰੂ ਕਰਨਾ ਵੱਖਰੇ ਟਾਈਮਰਾਂ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਹਨ। strongSwan ਮੁੜ-ਭੇਜਣ ਬੈਕਆਫ਼ ਦਾ IKE ਲਈ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ, ਅਤੇ OpenVPN ਕੋਲ ਵੱਖਰੇ ਅਰਥਾਂ ਨਾਲ ਆਪਣੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਨਿਯੰਤਰਣ ਹਨ। ਇੱਕ ਵਿੱਚੋਂ ਦੂਜੇ ਵਿੱਚ ਸੰਖਿਆ ਕਾਪੀ ਕਰਨਾ ਮੰਨ ਲੈਂਦਾ ਹੈ ਕਿ ਮਕੈਨਿਜ਼ਮ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਪਰ ਉਹ ਨਹੀਂ ਮਿਲਦੇ। ਤੁਸੀਂ ਕਿਹੜਾ ਅੰਤਰਾਲ ਦੇਖ ਰਹੇ ਹੋ ਇਹ ਤੈਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੌਗ ਦਾ ਕ੍ਰਮ ਪੜ੍ਹੋ।
ਲੌਗ ਵਿੱਚ ਇੱਕ ਚੁੱਪ ਮਿੰਟ ਦਾ ਮਤਲਬ ਜ਼ਰੂਰੀ ਨਹੀਂ ਜੰਮੀ ਪ੍ਰਕਿਰਿਆ ਹੋਵੇ। ਇਹ ਘਾਤਾਂਕੀ ਬੈਕਆਫ਼ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਠੀਕ ਉਹੀ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸ ਲਈ ਇਹ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਸੀ।
ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਪੜਾਅ ਹੌਲੀ ਹੈ?
ਜੇ ਲੌਗ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੋਸ਼ਿਸ਼ਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਗਲਤੀ ਨਾਲ ਅਸਫਲ ਹੋ ਰਹੀਆਂ ਹਨ, ਤਾਂ ਕੋਈ ਟਾਈਮਰ ਬਦਲਾਅ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਗਲਤ ਹੈ। ਜੇ ਕੋਸ਼ਿਸ਼ਾਂ ਬਿਲਕੁਲ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾ ਰਹੀਆਂ, ਤਾਂ ਕਲਾਇੰਟ ਆਪਣੀ ਉਡੀਕ ਵਿੰਡੋ ਵਿੱਚ ਹੈ ਅਤੇ ਸ਼ਡਿਊਲ ਹੀ ਹੱਲ ਹੈ। ਜੇ ਕੋਸ਼ਿਸ਼ਾਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਪਹੁੰਚ ਜਾਂ ਗੈਰਹਾਜ਼ਰ ਸਰੋਤੇ ਵਿੱਚ ਹੈ, ਅਤੇ ਤੇਜ਼ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਸਿਰਫ਼ ਲੌਗ ਭਰਦੀ ਹੈ। ਉਨ੍ਹਾਂ ਤਿੰਨਾਂ ਹਾਲਤਾਂ ਦਾ ਵੱਖਰਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਸਮੇਂ ਦੀ ਸਮੱਸਿਆ ਹੈ।
ਕਿਸੇ ਸੰਖਿਆ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲਤਾ ਦੀ ਸ਼੍ਰੇਣੀ ਬਣਾਓ।
ਟਾਈਮਰ ਘਟਾਉਣਾ ਕਦੋਂ ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਕਦੋਂ ਨਹੀਂ
ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਦੀ ਉੱਪਰੀ ਹੱਦ ਘਟਾਓ ਜਦੋਂ ਮੁੱਖ ਖ਼ਰਚ ਛੋਟੇ, ਵਾਰ-ਵਾਰ ਹੋਣ ਵਾਲੇ ਬੰਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦੀ ਉਡੀਕ ਹੈ, ਜਿਵੇਂ ਐਕਸੈਸ ਪੁਆਇੰਟਾਂ ਵਿਚਕਾਰ ਘੁੰਮਦਾ ਲੈਪਟਾਪ। ਜਦੋਂ ਅਸਫਲਤਾਵਾਂ ਲੰਮੀਆਂ ਜਾਂ ਘੱਟ ਹੋਣ ਤਾਂ ਇਸਨੂੰ ਛੇੜੋ ਨਾ, ਕਿਉਂਕਿ ਹਮਲਾਵਰ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਠੀਕ ਉਸੇ ਪਲ ਭਾਰ ਵਧਾਉਂਦੀ ਹੈ ਜਦੋਂ ਕਨਸੈਂਟ੍ਰੇਟਰ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਸਭ ਤੋਂ ਘੱਟ ਸਮਰੱਥ ਹੁੰਦਾ ਹੈ। ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਇੱਕ ਪੈਰਾਮੀਟਰ ਬਦਲੋ, ਇਸਨੂੰ ਦਰਜ ਕਰੋ, ਅਤੇ ਸੁਧਰਿਆ ਮੰਨਣ ਦੀ ਥਾਂ ਅਗਲੀ ਰਿਕਵਰੀ ਨੂੰ ਮਾਪੋ।
ਹਰ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕਾਪੀ ਕੀਤਾ ਬਹੁਤ ਘੱਟ ਟਾਈਮਆਉਟ ਬਿਨਾਂ ਮਾਪ ਦੀ ਟਿਊਨਿੰਗ ਦੀ ਆਮ ਅੰਤਿਮ ਹਾਲਤ ਹੈ।
ਕਲਾਇੰਟ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿਆਰੀ ਜਾਂਚੋ
ਕੁਝ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੱਕ ਕਲਾਇੰਟ ਨੂੰ ਅਕਸਰ ਦਿਸਦਾ ਨਹੀਂ ਕਿ ਨੈੱਟਵਰਕ ਵਰਤੋਂਯੋਗ ਹੈ। ਕੈਪਟਿਵ ਪੋਰਟਲ, DHCP ਨਵੀਨੀਕਰਨ ਜਾਂ ਰੂਟ ਬਦਲਾਅ ਇਸਨੂੰ ਇਹ ਸਭ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕੀਤੇ ਸ਼ਡਿਊਲ 'ਤੇ ਉਡੀਕਣ ਲਈ ਛੱਡ ਸਕਦੇ ਹਨ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਨੈੱਟਵਰਕ ਹਾਲਤ ਦੇ ਬਦਲਾਅ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਅਗਲੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਇੱਕੋ ਘੜੀ 'ਤੇ ਦੇਖੋ, ਅਤੇ ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿਸਦੀ ਉਡੀਕ ਹੈ। ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਨੈੱਟਵਰਕ-ਤਿਆਰ ਘਟਨਾ ਦਾ ਸਮਾਂ-ਛਾਪ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਸਮਾਂ-ਛਾਪ ਨੋਟ ਕਰਨਾ।
ਪੱਕਾ ਕਰੋ ਕਿ ਉਡੀਕ ਦੌਰਾਨ ਸਿੱਧਾ ਟ੍ਰੈਫਿਕ ਵੀ ਅਜੇ ਰੁਕਿਆ ਹੋਇਆ ਹੈ, ਕਿਉਂਕਿ ਟ੍ਰੈਫਿਕ ਲੀਕ ਕਰਨ ਵਾਲਾ ਤੇਜ਼ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਸੁਧਾਰ ਨਹੀਂ ਹੈ।
ਕੀ ਦਰਜ ਕਰਨਾ ਹੈ
ਕਿਹੜਾ ਟਾਈਮਰ ਬਦਲਿਆ, ਕਿਹੜੇ ਮੁੱਲ ਤੋਂ ਕਿਹੜੇ ਮੁੱਲ ਵਿੱਚ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਰਿਕਵਰੀ ਕਿਵੇਂ ਲੱਗੀ, ਇਹ ਲਿਖੋ। ਕਲਾਇੰਟ ਦਾ ਸੰਸਕਰਣ ਵੀ ਨੋਟ ਕਰੋ, ਕਿਉਂਕਿ ਡਿਫ਼ਾਲਟ ਰਿਲੀਜ਼ਾਂ ਵਿਚਕਾਰ ਬਦਲਦੇ ਹਨ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਨਾ ਕੀਤਾ ਬਹੁਤ ਘੱਟ ਟਾਈਮਆਉਟ ਪ੍ਰੋਫਾਈਲ ਪੜ੍ਹਨ ਵਾਲੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਉਲਝਾ ਦੇਵੇਗਾ।
ਉਹ ਰਿਕਾਰਡ ਅਗਲੇ ਸਾਫ਼ਟਵੇਅਰ ਅੱਪਗ੍ਰੇਡ ਨੂੰ ਪ੍ਰਯੋਗ ਦੀ ਥਾਂ ਤੁਲਨਾ ਬਣਾ ਦਿੰਦਾ ਹੈ।