Azure VPN Client 3.4 ਹਰ ਘੰਟੇ ਡਿਸਕਨੈਕਟ ਹੁੰਦਾ ਹੈ: ਸਾਈਨ-ਇਨ ਬਾਰੰਬਾਰਤਾ

ਇੱਕ ਵਰਤੋਂਕਾਰ ਜੁੜਦਾ ਹੈ, ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਹਰ ਘੰਟੇ ਇੱਕ ਵਾਰ Microsoft Entra ਨਾਲ ਪਰਮਾਣੀਕਰਣ ਸਮਾਪਤ ਹੋ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਸੰਦੇਸ਼ ਨਾਲ ਡਿਸਕਨੈਕਟ ਹੁੰਦਾ ਹੈ। ਦੁਬਾਰਾ ਜੁੜਨਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਚੱਕਰ ਸਟਾਪਵਾਚ ਵਾਂਗ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ। ਜਿੱਥੇ ਕੁਝ ਤੈਨਾਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਅਜਿਹੇ point-to-site ਗੇਟਵੇ ’ਤੇ ਇਹ ਪੈਟਰਨ ਸ਼ਨਾਖਤ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਟਨਲ ਵੱਲ ਨਹੀਂ। Azure VPN Client 3.4.0 ਨੇ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਦੌਰਾਨ ਸ਼ਰਤ ਪਹੁੰਚ ਦੀ ਸਾਈਨ-ਇਨ ਬਾਰੰਬਾਰਤਾ ਲਾਗੂ ਕਰਨੀ ਸ਼ੁਰੂ ਕੀਤੀ, ਅਜਿਹੀ ਨੀਤੀ ਜਿਹਨੂੰ ਪਹਿਲੇ ਕਲਾਇੰਟ ਸਿਰਫ਼ ਸਾਈਨ-ਇਨ ਸਮੇਂ ਜਾਂਚਦੇ ਸਨ।

ਹੇਠ ਦਿੱਤੀਆਂ ਛੇ ਜਾਂਚਾਂ ਕ੍ਰਮਵਾਰ ਕਰੋ। ਹਰ ਜਾਂਚ ਸਮਾਂ-ਸਾਰਣੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਜਾਂ ਉਸਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਛੇਤੀ ਰੁਕਣਾ ਗੇਟਵੇ ਨੂੰ ਬਿਨਾਂ ਕਾਰਨ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ।

ਸਟੈਪ 1: ਸਟੀਕ ਸੰਦੇਸ਼ ਪੜ੍ਹੋ

ਸ਼ਬਦ ਜਾਣ ਸ਼ਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀ ਹੈ। Entra ਪਰਮਾਣੀਕਰਣ ਦੇ ਸਮਾਪਤ ਹੋਣ ਵਾਲਾ ਸੰਦੇਸ਼ ਟੋਕਨ ਬਾਰੇ ਹੈ; ਟਨਲ ਜਾਂ ਸੁਰੱਖਿਆ ਸੰਬੰਧ ਦੀ ਗਲਤੀ ਨਹੀਂ। ਜੁੜਨ ਤੋਂ ਡਿਸਕਨੈਕਟ ਤੱਕ ਲੱਗਾ ਸਮਾਂ ਵੀ ਲਿਖੋ, ਕੰਮਕਾਜ ਦੇ ਦਿਨ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਨਹੀਂ।

ਜੇ ਵਰਤੋਂਕਾਰ ਤੁਰੰਤ ਦੁਬਾਰਾ ਜੁੜ ਸਕਦਾ ਹੈ ਅਤੇ ਗੇਟਵੇ ਹਜੇ ਵੀ ਸਿਹਤਮੰਦ ਟਨਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਟੋਕਨ ਦੀ ਮਿਆਦ ਪੂਰੀ ਹੋਣ ਵੇਖ ਰਹੇ ਹੋ, ਮਰੇ ਪੀਅਰ ਨਹੀਂ।

ਸਟੈਪ 2: ਕਲਾਇੰਟ ਦਾ ਸੰਸਕਰਣ ਜਾਣੋ

ਸੰਸਕਰਣ ਐਪ ਵਿੱਚ ਪੜ੍ਹੋ, ਤੈਨਾਤੀ ਰਿਕਾਰਡ ਵਿੱਚ ਨਹੀਂ। ਬਦਲਾਅ 3.4.0 ਨਾਲ ਆਇਆ, ਇਸ ਲਈ 3.3.1 ਅਤੇ ਹੋਰ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਨੀਤੀ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਸਥਾਪਿਤ ਟਨਲ ਨੂੰ ਜੀਵਿਤ ਰੱਖਦੇ ਹਨ। ਪੁਰਾਣੇ ਬਿਲਡ ਵਾਲਾ ਇੱਕ ਗੈਰ-ਪ੍ਰਬੰਧਿਤ ਲੈਪਟਾਪ ਬਿਲਕੁਲ ਠੀਕ ਚੱਲਦਾ ਹੈ ਜਦੋਂ ਬਾਕੀ ਟੀਮ ਹਰ ਘੰਟੇ ਡਿਗਦੀ ਹੈ: ਇਹੀ ਕਿਸਮ ਦੀ ਵੱਖਰਤਾ ਲੋਕਾਂ ਨੂੰ ਗੇਟਵੇ ਵੱਲ ਵਾਪਸ ਭੇਜਦੀ ਹੈ। ਸੰਸਕਰਣ ਕਲਾਇੰਟ ਦੀ ਖਾਸੀਅਤ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿਹੜਾ ਬਿਲਡ ਜੁੜਿਆ ਹੈ।

ਪਹਿਲਾਂ ਇੱਕ ਟੈਸਟ ਡਿਵਾਇਸ ਅੱਪਡੇਟ ਕਰੋ ਅਤੇ ਘੜੀ ਵੇਖੋ। ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਨੀਤੀ ਦੇ ਅੰਤਰਾਲ ’ਤੇ ਡਿਗਣ ਵਾਲਾ ਡਿਵਾਇਸ ਉਤਪਾਦਨ ਨੀਤੀ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਢਾਂਚੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ।

ਸਟੈਪ 3: ਪਤਾ ਲਗਾਓ ਨੀਤੀ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ

ਸਾਈਨ-ਇਨ ਬਾਰੰਬਾਰਤਾ Azure VPN ਐਂਟਰਪ੍ਰਾਈਜ਼ ਐਪ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲੀ ਨੀਤੀ ਵਿੱਚ ਸ਼ਰਤ ਪਹੁੰਚ ਦੀ ਸੈਟਿੰਗ ਹੈ। ਇਹ VPN ਗੇਟਵੇ ਸੰਸਾਧਨ ’ਤੇ ਨਹੀਂ, point-to-site ਸੰਰਚਨਾ ਵਿੱਚ ਨਹੀਂ ਅਤੇ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਇਲ ਵਿੱਚ ਨਹੀਂ। ਨੀਤੀਆਂ ਦੀ ਸੂਚੀ ਵਿੱਚ Azure VPN ਐਪ ਲੱਭੋ ਅਤੇ ਸੈਸ਼ਨ ਕੰਟਰੋਲ ਪੜ੍ਹੋ।

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

ਸਟੈਪ 4: ਗਣਿਤ ਕਰੋ

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

ਜੇ ਅੰਤਰ ਉਸ ਜੋੜ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਤਾਂ ਸਮਾਂ-ਸਾਰਣੀ ਦੀ ਧਾਰਨਾ ਗਲਤ ਹੈ ਅਤੇ ਨੀਤੀ ਨੂੰ ਸਮਾਯੋਜਿਤ ਕਰਨਾ ਬੰਦ ਕਰੋ।

ਸਟੈਪ 5: ਸਮਾਂ-ਸਾਰਣੀ ਨੂੰ rekey ਤੋਂ ਵੱਖ ਕਰੋ

IPsec rekey, ਮਰੇ ਪੀਅਰ ਦੀ ਪਛਾਣ ਅਤੇ ਨਿਸ਼ਕਿਰਿਆਤਾ ਦੀਆਂ ਸਮਾਂ-ਸੀਮਾਵਾਂ ਅਣਿਯਮਿਤ ਕਟੌਤੀਆਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ ਜੋ ਟ੍ਰੈਫਿਕ ਦੀ ਮਾਤਰਾ ਜਾਂ ਖਾਮੋਸ਼ੀ ਨਾਲ ਜੁੜੀਆਂ ਹਨ, ਸਟਾਪਵਾਚ ਨਾਲ ਨਹੀਂ। ਅੱਧ-ਵਿਚਕਾਰ ਡਿਗਣ ਵਾਲਾ ਵਰਤੋਂਕਾਰ ਅਤੇ ਨਿਸ਼ਕਿਰਿਆ ਦੁਪਹਿਰ ਤੋਂ ਬਾਅਦ ਡਿਗਣ ਵਾਲਾ ਵਰਤੋਂਕਾਰ ਵੱਖਰੇ ਢਾਂਚੇ ਦੱਸਦੇ ਹਨ। ਪੁੱਛੋ ਕਿ ਡਿਸਕਨੈਕਟ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤੋਂਕਾਰ ਕੀ ਕਰ ਰਿਹਾ ਸੀ।

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

ਸਟੈਪ 6: ਬਿਨਾਂ ਹੈਰਾਨ ਤੈਨਾਤ ਕਰੋ

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

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