Azure OpenVPN ਟਨਲ ਲਗਭਗ ਹਰ ਸੱਠ ਸਕਿੰਟ ਬਾਅਦ ਕਿਉਂ ਡਿੱਗਦੀ ਹੈ

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

ਕਿਸੇ ਵੀ ਟਾਈਮਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਲਾਈਨ ਪੜ੍ਹੋ।

ਕਥਾ: ਰਸਤੇ ਵਿੱਚ ਕੁਝ ਟਨਲ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ

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

ਤਾਲ ਹੀ ਲਾਭਦਾਇਕ ਸੁਰਾਗ ਹੈ। ਟਾਈਮਰ ਇਹ ਪੈਦਾ ਕਰਦੇ ਹਨ; ਪੈਕਟ ਗੁਆਉਣਾ ਘੱਟ ਹੀ।

ਟਾਈਮਰ ਤੋਂ ਪਹਿਲਾਂ ਡਿਸਕਨੈਕਟ ਦਾ ਕਾਰਨ ਪੜ੍ਹੋ

OpenVPN ਆਪਣੇ ਕਾਰਨ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਨਾਮ ਵੱਖਰੀ ਉਪ-ਪ੍ਰਣਾਲੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। Session invalidated: KEEPALIVE_TIMEOUT ਖ਼ਤਮ ਹੋ ਰਿਹਾ ਟਾਈਮਰ ਹੈ, ਇਸ ਲਈ ਦੋਵੇਂ ਸਿਰਿਆਂ ’ਤੇ ping ਅਤੇ ping-restart ਮੁੱਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। AUTH_FAILED ਪ੍ਰਮਾਣ ਪੱਤਰ ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਦੀ ਸਥਿਤੀ ਹੈ, ਅਤੇ ਕੋਈ ਟਾਈਮਰ ਬਦਲਾਅ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ। TLS ਗਲਤੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੋਵੇਂ ਧਿਰਾਂ keepalive ਪੜਾਅ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚੀਆਂ।

ਕਨੈਕਟ ਦਾ ਸਮਾਂ, ਡਿਸਕਨੈਕਟ ਦਾ ਸਮਾਂ ਅਤੇ ਇਹ ਕਿ ਅੰਤਰਾਲ ਸਕਿੰਟ ਤੱਕ ਸਥਿਰ ਹੈ ਜਾਂ ਨਹੀਂ, ਦਰਜ ਕਰੋ। ਉਹੀ ਇੱਕ ਮਾਪ ਨਿਰਧਾਰਿਤ ਸਮਾਂ-ਸਾਰਣੀ ਨੂੰ ਸੰਜੋਗ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ਸਥਿਰ ਅੰਤਰਾਲ ਟਾਈਮਰ ਹੈ। ਖਿਸਕਦਾ ਅੰਤਰਾਲ ਵਧੇਰੇ ਸੰਭਾਵਤ ਤੌਰ ’ਤੇ ਰਸਤੇ ਦੀ ਸਮੱਸਿਆ ਜਾਂ ਥਾਂ ਬਦਲੀ ਸੈਸ਼ਨ ਹੈ।

ਦੋ keepalive ਟਾਈਮਰ ਜੋ ਕਦੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋਏ

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

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

ਕਲਾਇੰਟ ਵੱਲ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਫ਼ਾਈਲ ਦੇ ਸਭ ਤੋਂ ਉੱਪਰਲੇ ਪੱਧਰ ’ਤੇ, ਹਰ ਇਨਲਾਈਨ ਬਲਾਕ ਤੋਂ ਬਾਹਰ, ਟਾਈਮਰਾਂ ਨੂੰ ਨਿਸ਼ਕ੍ਰਿਯ ਕਰੋ:

keepalive 0 0

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

ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਾਮ ਤੁਹਾਡੇ ਪੈਰਾਂ ਹੇਠੋਂ ਖਿਸਕ ਸਕਦਾ ਹੈ

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

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

ਕੀ ਬਦਲਣਾ ਹੈ, ਅਤੇ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ

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

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

ਇਹਨਾਂ ਚਾਰ ਜਾਂਚਾਂ ਤੋਂ ਬਾਅਦ ਹੀ ਗੇਟਵੇ ਸੈਟਿੰਗਾਂ ਬਦਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।