ਪਹਿਲਾ ਸੈਸ਼ਨ ਜਿੱਤਦਾ ਹੈ: ਬੇਦਖਲੀ ਤੋਂ ਪਹਿਲਾਂ OpenVPN ਲੌਗਇਨ ਨੂੰ ਰੋਕਣਾ
ਬਾਅਦ ਦੇ ਲੌਗਇਨ ਨੂੰ ਰੱਦ ਕਰਨਾ ਪੁਰਾਣੇ ਨੂੰ ਬਦਲਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। ਫ਼ੈਸਲਾ ਉਸੇ ਨਾਮ ਦੀ ਬੇਦਖਲੀ ਤੋਂ ਪਹਿਲਾਂ ਲੈਣਾ ਪਵੇਗਾ, ਅਤੇ ਸਲਾਟ ਜਾਂਚ ਪਰਮਾਣੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਪ੍ਰਤੀ ਖਾਤਾ ਇੱਕ ਸੈਸ਼ਨ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੀ ਨੀਤੀ ਦੂਜੇ ਲੌਗਇਨ ਦੇ ਆਉਣ ਤੱਕ ਤੈਅ ਲੱਗਦੀ ਹੈ। ਦੋ ਨਤੀਜੇ ਸੰਭਵ ਹਨ: ਨਵਾਂ ਆਉਣ ਵਾਲਾ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਦੀ ਥਾਂ ਲੈਂਦਾ ਹੈ, ਜਾਂ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਸਲਾਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਿਰਫ਼ ਦੂਜਾ ਹੀ ਪਹਿਲਾ ਸੈਸ਼ਨ ਜਿੱਤਦਾ ਹੈ ਨੀਤੀ ਹੈ। ਜਿਸ ਕਲਾਇੰਟ ਚੋਣ ਵੱਲ ਬਹੁਤੇ ਲੋਕ ਜਾਂਦੇ ਹਨ ਉਹ ਸਮਕਾਲੀਤਾ ਚਾਲੂ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸ ਲਈ ਇਹ ਨਤੀਜਾ ਨਹੀਂ ਦਿੰਦੀ।
ਇੱਕ ਸੈਟਿੰਗ ਪਿੱਛੇ ਦੋ ਸਮਝੌਤੇ ਲੁਕੇ ਹੋਏ ਹਨ
ਸਮਕਾਲੀਤਾ ਬੰਦ ਹੋਣ 'ਤੇ, ਉਹੀ ਸਰਟੀਫਿਕੇਟ ਨਾਮ ਲੈ ਕੇ ਆਉਣ ਵਾਲਾ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਪਹਿਲਾਂ ਚੱਲ ਰਹੇ ਸੈਸ਼ਨ ਨੂੰ ਹਟਾ ਸਕਦਾ ਹੈ। ਸਮਕਾਲੀਤਾ ਚਾਲੂ ਕਰਨ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਕਈ ਸੈਸ਼ਨਾਂ ਦੀ ਆਗਿਆ ਮਿਲਦੀ ਹੈ, ਜੋ ਸੀਮਾ ਦੇ ਉਲਟ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਥਿਤੀ ਰੱਦ ਕਰਨ ਦੀ ਨੀਤੀ ਨਹੀਂ, ਇਸ ਲਈ ਫ਼ੈਸਲਾ ਬਿਲਕੁਲ ਕਿਤੇ ਹੋਰ ਲੈਣਾ ਪਵੇਗਾ।
ਕੁਝ ਵੀ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮਝੌਤਾ ਲਿਖੋ: ਕਿਸ ਨੂੰ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਕਿਹੜਾ ਸਬੂਤ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਾਫ਼ ਡਿਸਕਨੈਕਟ ਤੋਂ ਬਿਨਾਂ ਸੈਸ਼ਨ ਮਰ ਜਾਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਜਿਸ ਨੀਤੀ ਨੂੰ ਕਿਸੇ ਨੇ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਕਿਹਾ, ਉਸ ਦੀ ਬਾਅਦ ਵਿੱਚ ਜਾਂਚ ਨਹੀਂ ਹੋ ਸਕਦੀ।
ਬੇਦਖਲੀ ਤੁਹਾਡੇ ਕਨੈਕਟ ਹੁੱਕ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ
2.6 ਸਰਵਰ ਕੋਡ ਮਾਰਗ ਵਿੱਚ, ਨਵੇਂ ਕਲਾਇੰਟ ਦੀ ਸ਼ੁਰੂਆਤੀ ਤਿਆਰੀ ਸਮਕਾਲੀਤਾ ਬੰਦ ਹੋਣ 'ਤੇ ਉਸੇ ਨਾਮ ਦੇ ਮੌਜੂਦਾ ਇੰਸਟੈਂਸ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਉਹ ਹਟਾਉਣਾ ਕਨੈਕਟ ਹੈਂਡਲਰ ਲੜੀ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਨਕਲ ਦੇਖ ਕੇ ਅਸਫਲਤਾ ਵਾਪਸ ਕਰਨ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਨਵੇਂ ਨੂੰ ਉਦੋਂ ਰੱਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟਿਆ ਜਾ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ - ਠੀਕ ਉਹੀ ਨਤੀਜਾ ਜਿਸ ਨੂੰ ਨੀਤੀ ਰੋਕਣਾ ਚਾਹੁੰਦੀ ਸੀ। Upstream ਲਾਗੂਕਰਨ ਵਿੱਚ ਕਾਲਬੈਕ ਦਾ ਕ੍ਰਮ ਹੀ ਤੁਹਾਡੇ ਬਿਲਡ ਲਈ ਇੱਕੋ ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਹੈ।
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
ਸਟੇਟਸ ਫਾਈਲ ਪੋਲ ਕਰਨਾ ਵੀ ਦਰਵਾਜ਼ਾ ਨਹੀਂ ਹੈ। ਇਕੱਠੇ ਆਉਣ ਵਾਲੇ ਦੋ ਯਤਨ ਦੋਵੇਂ ਖਾਲੀ ਸਲਾਟ ਦੇਖ ਸਕਦੇ ਹਨ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਇਸ ਨੂੰ ਪੱਕਾ ਕਰੇ, ਅਤੇ ਦੋਵੇਂ ਅੱਗੇ ਵਧਦੇ ਹਨ।
ਫ਼ੈਸਲਾ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿੱਚ ਲੈ ਜਾਓ
ਸਰਟੀਫਿਕੇਟ ਦੀ ਜਾਂਚ ਤੋਂ ਬਾਅਦ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਫ਼ੈਸਲਾ ਲੈ ਸਕਦਾ ਹੈ। ਉਸ ਵਿਵਸਥਾ ਵਿੱਚ ਕੰਟਰੋਲਰ ਨਿਰੀਖਕ ਨਹੀਂ ਹੈ: ਉਹ ਹਰ ਜੁੜਨ ਵਾਲੇ ਕਲਾਇੰਟ ਇੰਸਟੈਂਸ ਨੂੰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਕਿ ਉਹ ਇੰਸਟੈਂਸ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜਵਾਬ ਸਥਾਪਨਾ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਰੱਦ ਕਰਨਾ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਨੂੰ ਅਛੂਤਾ ਛੱਡਦਾ ਹੈ। ਉਹੀ ਚੈਨਲ ਡਿਸਕਨੈਕਟ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਕੰਟਰੋਲਰ ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਸਲਾਟ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਛੱਡਿਆ ਗਿਆ।
ਹਰ ਨਵੇਂ ਇੰਸਟੈਂਸ ਨੂੰ ਇਸ ਦਰਵਾਜ਼ੇ ਵਿੱਚੋਂ ਲੰਘਣਾ ਪਵੇਗਾ, ਜਿਸ ਵਿੱਚ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਅਤੇ ਬਿਨਾਂ ਸੰਕੇਤ ਦੇ ਮੁੜ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਨ ਵਾਲਾ ਕੋਈ ਵੀ ਮਾਰਗ ਸ਼ਾਮਲ ਹੈ। ਜਿਸ ਦਰਵਾਜ਼ੇ ਤੱਕ ਕੁਝ ਇੰਸਟੈਂਸ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ ਉਹ ਕੁਝ ਨਹੀਂ ਬਚਾਉਂਦਾ, ਅਤੇ ਇਹ ਖੁੰਝੀ ਕਿਸੇ ਦੇ ਬਾਈਪਾਸ ਅਜ਼ਮਾਉਣ ਤੱਕ ਅਦਿੱਖ ਰਹਿੰਦੀ ਹੈ।
ਟੋਕਨ ਦਰਵਾਜ਼ੇ ਦੇ ਕੋਲੋਂ ਲੰਘ ਸਕਦੇ ਹਨ
ਇੱਕ ਵਾਰ ਟੋਕਨ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਸਰਵਰ ਇਸ ਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਮਾਨਤਾ ਦੇ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸ ਕਨੈਕਸ਼ਨ ਲਈ ਬਾਹਰੀ ਪ੍ਰਮਾਣਿਕਤਾ ਛੱਡ ਸਕਦਾ ਹੈ. ਪ੍ਰਬੰਧਨ ਕਾਲ ਕਦੇ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਸਿਰਫ਼ ਉੱਥੇ ਲਾਗੂ ਕੀਤੀ ਸਲਾਟ ਜਾਂਚ ਨਵੇਂ ਇੰਸਟੈਂਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖਦੀ। ਇਹ ਵਿਵਹਾਰ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਸੁਵਿਧਾ ਅਤੇ ਸਮਕਾਲੀਤਾ ਨੀਤੀ ਲਈ ਪੁਲਾਂਘ ਹੈ। ਟੋਕਨ-ਪ੍ਰਮਾਣਿਤ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਬਰਾਬਰ ਦੀ ਅਧਿਕਾਰਤ ਜਾਂਚ ਵਿੱਚੋਂ ਲੰਘਣ ਦਿਓ, ਜਾਂ ਜਦੋਂ ਨੀਤੀ ਹਰ ਕਨੈਕਸ਼ਨ 'ਤੇ ਫ਼ੈਸਲਾ ਮੰਗਦੀ ਹੈ ਤਾਂ ਟੋਕਨ ਮਾਰਗ ਬੰਦ ਕਰੋ।
ਹਰ ਟੋਕਨ ਨੂੰ ਬਿਨਾਂ ਸ਼ਰਤ ਸਵੀਕਾਰ ਕਰਕੇ ਇਸ ਦੀ ਭਰਪਾਈ ਨਾ ਕਰੋ। ਮਿਆਦ ਪੁੱਗਿਆ ਜਾਂ ਅਵੈਧ ਟੋਕਨ ਫਿਰ ਵੀ ਅਸਫਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਬਾਕੀ ਸਭ ਵਾਂਗ ਉਸੇ ਫ਼ੈਸਲਾ-ਬਿੰਦੂ ਰਾਹੀਂ ਅਸਫਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਰਾਖਵਾਂਕਰਨ ਨੂੰ ਇੰਸਟੈਂਸ ਨਾਲ ਬੰਨ੍ਹੋ, ਪਤੇ ਨਾਲ ਨਹੀਂ
ਪਤਾ ਕਮਜ਼ੋਰ ਪਛਾਣ ਹੈ: ਉਸੇ ਲੈਪਟਾਪ ਤੋਂ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਕਿਸੇ ਹੋਰ ਪਤੇ ਤੋਂ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਨਕਲ ਕੀਤਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਉਸੇ ਪਤੇ ਤੋਂ ਆ ਸਕਦਾ ਹੈ। ਰਾਖਵਾਂਕਰਨ ਨੂੰ ਸਰਵਰ ਵੱਲੋਂ ਦਿੱਤੇ ਕਲਾਇੰਟ ਇੰਸਟੈਂਸ ਨਾਲ ਬੰਨ੍ਹੋ, ਤਾਂ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤੇ ਇੰਸਟੈਂਸ ਦੀ ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਮਾਲਕ ਵਜੋਂ ਪਛਾਣੀ ਜਾਵੇ। ਨਵੇਂ ਇੰਸਟੈਂਸ ਪਛਾਣਕਰਤਾ ਨੂੰ ਉਹੀ ਟੋਕਨ ਪੇਸ਼ ਕਰਨ 'ਤੇ ਵੀ ਪਹਿਲਾ ਜਿੱਤਦਾ ਹੈ ਫ਼ੈਸਲੇ ਰਾਹੀਂ ਆਪਣਾ ਸਲਾਟ ਲੈਣਾ ਪਵੇਗਾ।
ਸਿਰਫ਼ ਅਸਫਲ ਯਤਨ ਦਾ ਰਾਖਵਾਂਕਰਨ ਛੱਡੋ। ਪੁਰਾਣੇ ਯਤਨ ਤੋਂ ਦੇਰ ਨਾਲ ਆਇਆ ਡਿਸਕਨੈਕਟ ਘਟਨਾ ਨਵੇਂ ਮਾਲਕ ਦਾ ਸਲਾਟ ਨਹੀਂ ਮਿਟਾ ਸਕਦਾ, ਇਸ ਲਈ ਛੱਡਣਾ ਖਾਤੇ ਦੀ ਥਾਂ ਇੰਸਟੈਂਸ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। ਕੰਟਰੋਲਰ ਦੇ ਮੁੜ-ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕਿਸੇ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰਗਰਮ ਸੈਸ਼ਨ ਮਿਲਾਓ, ਅਤੇ ਖਾਤੇ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਹਰ ਗੇਟਵੇ 'ਤੇ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਕਰੋ।
ਸੱਚਮੁੱਚ ਪੁਰਾਣੇ ਸਲਾਟ ਦੀ ਵਾਪਸੀ ਕਿਵੇਂ ਹੋਵੇਗੀ, ਇਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਤੈਅ ਕਰੋ। ਪ੍ਰਬੰਧਕ ਨੂੰ ਇਸ ਨੂੰ ਸਾਫ਼ ਕਰਨ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਹ ਮਾਰਗ ਸਿਰਫ਼ ਮੁੜ-ਕਨੈਕਟ ਕਲਿੱਕ ਕਰਨ ਵਾਲੇ ਵਰਤੋਂਕਾਰ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਮਹੱਤਵਪੂਰਨ ਜੋੜਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ: ਲਗਭਗ ਇਕੋ ਸਮੇਂ ਦੋ ਲੌਗਇਨ, ਸਾਫ਼ ਕਟੌਤੀ ਤੋਂ ਬਾਅਦ ਮੁੜ-ਕਨੈਕਸ਼ਨ, ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਦੀ ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ, ਰੱਦ ਕੀਤਾ ਨਵਾਂ ਆਉਣ ਵਾਲਾ ਅਤੇ ਕੰਟਰੋਲਰ ਦਾ ਮੁੜ-ਚਾਲੂ। ਹਰ ਮਾਮਲੇ ਵਿੱਚ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਵਰਤੋਂਯੋਗ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਨੂੰ ਹੋਰ ਖਾਤਿਆਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਏ ਬਿਨਾਂ ਰੱਦ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।