ਵੱਡੀ OpenVPN ਕੁੰਜੀ ਰੀਕੀ ਟਾਈਮਰ ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਹਟਾਉਂਦੀ

AES-256 ਜਾਂ ਲੰਮੀ ਕੁੰਜੀ ਚੁਣਨਾ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਉਹ ਕੁੰਜੀ ਕਿੰਨਾ ਚਿਰ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਕੁੰਜੀ ਦੀ ਤਾਕਤ ਐਲਗੋਰਿਦਮ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ; ਰੀਕੀ ਨੀਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਸੈਸ਼ਨ ਕਦੋਂ ਨਵੀਂ ਕੁੰਜੀ ਸਮੱਗਰੀ ਲੈਂਦਾ ਹੈ। ਕੋਈ ਤੈਨਾਤੀ ਉਪਲਬਧ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਸਾਈਫ਼ਰ ਚੁਣ ਕੇ ਵੀ ਨਵੀਨੀਕਰਨ ਵਿੱਚ ਗ਼ਲਤ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਫ਼ੈਸਲੇ ਵੱਖਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਲਏ ਜਾਂਦੇ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣ ਨਾਲ ਜਾਂ ਤਾਂ ਬੇਲੋੜੀ ਸਾਈਫ਼ਰ ਤਬਦੀਲੀ ਹੁੰਦੀ ਹੈ ਜਾਂ ਅਜਿਹਾ ਸੈਸ਼ਨ ਬਣਦਾ ਹੈ ਜੋ ਚੁੱਪਚਾਪ ਆਪਣੀ ਨੀਤੀ ਤੋਂ ਵੱਧ ਜਿਉਂਦਾ ਹੈ।

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

ਕੁੰਜੀ ਦੀ ਤਾਕਤ ਅਤੇ ਕੁੰਜੀ ਦੀ ਉਮਰ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ

ਸਾਈਫ਼ਰ ਅਤੇ ਕੁੰਜੀ ਦਾ ਆਕਾਰ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਫੜੇ ਗਏ ਟ੍ਰੈਫ਼ਿਕ 'ਤੇ ਹਮਲਾ ਕਿੰਨਾ ਮਹਿੰਗਾ ਹੋਵੇਗਾ। ਰੀਕੀ ਅੰਤਰਾਲ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਕੁੰਜੀ ਕਿੰਨਾ ਟ੍ਰੈਫ਼ਿਕ ਸੁਰੱਖਿਅਤ ਰੱਖਦੀ ਹੈ ਅਤੇ ਜ਼ਾਹਰ ਹੋਈ ਕੁੰਜੀ ਕਿੰਨਾ ਚਿਰ ਲਾਹੇਵੰਦ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਸੁਤੰਤਰ ਨਿਯੰਤਰਣ ਹਨ, ਅਤੇ ਮਜ਼ਬੂਤ ਸਾਈਫ਼ਰ ਸੈਸ਼ਨ ਦੀ ਸੁਰੱਖਿਅਤ ਉਮਰ ਨਹੀਂ ਵਧਾਉਂਦਾ। 'AES-256 ਵਰਤੋ' ਆਖਣ ਵਾਲ਼ੀ ਬਹੁਤੀ ਹਦਾਇਤ ਨਵੀਨੀਕਰਨ ਬਾਰੇ ਚੁੱਪ ਰਹਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਨਵੀਨੀਕਰਨ ਨੀਤੀ ਦਾ ਸਵਾਲ ਹੈ, ਐਲਗੋਰਿਦਮ ਦੀ ਚੋਣ ਨਹੀਂ।

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

ਰੀਕੀ ਦੇ ਤਿੰਨ ਟ੍ਰਿਗਰ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਪਾਸਾ ਉਨ੍ਹਾਂ ਨੂੰ ਚਲਾ ਸਕਦਾ ਹੈ

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

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

ਰੀਕੀ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਵਾਹ ਨੂੰ ਉਜਾਗਰ ਕਰਦੀ ਹੈ

ਮੁੜ ਗੱਲਬਾਤ ਨਵੀਂ TLS ਹੈਂਡਸ਼ੇਕ ਹੈ, ਭਾਵ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਰਾਹ ਦੁਬਾਰਾ ਚੱਲਦਾ ਹੈ। ਇੱਕ-ਵਾਰੀ ਕੋਡ, ਹਾਰਡਵੇਅਰ ਟੋਕਨ ਜਾਂ RADIUS ਚੁਣੌਤੀ ਵਰਤਣ ਵਾਲੀਆਂ ਤੈਨਾਤੀਆਂ ਇਹ ਔਖੇ ਢੰਗ ਨਾਲ ਜਾਣਦੀਆਂ ਹਨ: ਪਹਿਲਾ ਕਨੈਕਸ਼ਨ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਘੰਟੇ ਬਾਅਦ ਸੈਸ਼ਨ ਮਰ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਦੂਜੀ ਹੈਂਡਸ਼ੇਕ ਪਹਿਲਾਂ ਹੀ ਵਰਤਿਆ ਕੋਡ ਮੰਗਦੀ ਹੈ। auth-gen-token ਉਹ ਖੱਪਾ ਭਰਨ ਲਈ ਮੌਜੂਦ ਹੈ, ਸਰਵਰ ਨਵਾਂ ਇੰਟਰੈਕਟਿਵ ਲੌਗਇਨ ਮੰਗਣ ਦੀ ਥਾਂ ਮੁੜ ਗੱਲਬਾਤ ਲਈ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦਾ ਟੋਕਨ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ।

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

ਨਵੀਨੀਕਰਨ ਭਾਰ ਹੇਠ ਪਰਖੋ, ਇੱਕ ਮਿੰਟ ਦੇ ਸੈਸ਼ਨ ਵਿੱਚ ਨਹੀਂ

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

ਕਾਮਯਾਬ ਵੱਡੇ ਤਬਾਦਲੇ ਨੂੰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫ਼ਿਕ ਸੀਮਾ ਦਾ ਸਬੂਤ ਨਾ ਪੜ੍ਹੋ। ਇਹ ਸਿਰਫ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਰਾਹ ਅਤੇ ਗਿਣਕ ਉੱਨਾ ਟ੍ਰੈਫ਼ਿਕ ਝੱਲ ਸਕੇ।

ਦੋਵੇਂ ਚੋਣਾਂ ਦਰਜ ਕਰੋ

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

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