ਕੀ VPN ਦੀ ਐਂਟਰੋਪੀ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ? entropy_avail ਅਸਲ ਵਿੱਚ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ

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

ਇਹ ਮਿੱਥ ਕਿਉਂ ਬਚੀ ਰਹਿੰਦੀ ਹੈ

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

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

ਜਨਰੇਟਰ ਹਰ ਪੈਕਟ ਲਈ ਕੀ ਕਰਦਾ ਹੈ

OpenSSL 3 ਵਿੱਚ ਡਿਫ਼ਾਲਟ ਜਨਰੇਟਰ ਲੜੀ ਸੰਰਚਨਾ ਅਤੇ ਸਥਿਤੀ ਅਨੁਸਾਰ ਬੀਜਣ ਅਤੇ ਦੁਬਾਰਾ ਬੀਜਣ ਵਾਲੇ DRBG ਉਦਾਹਰਨਾਂ ਤੋਂ ਬਣਦੀ ਹੈ। OpenVPN 2.6 ਵਿੱਚ AEAD ਡੇਟਾ ਮਾਰਗ ਆਪਣਾ nonce ਪੈਕਟ ਦੇ ਕ੍ਰਮ ਨੰਬਰ ਤੋਂ ਪ੍ਰਤੀ-ਸੈਸ਼ਨ ਲੁਕਵੇਂ ਮੁੱਲ ਨਾਲ ਲੈਂਦਾ ਹੈ, ਜਦਕਿ ਪੁਰਾਣਾ CBC ਮਾਰਗ ਹਰ ਪੈਕਟ ਲਈ ਸਿਊਡੋ-ਬੇਤਰਤੀਬ IV ਲੈਂਦਾ ਹੈ। ਕੋਈ ਵੀ ਢੰਗ ਇਸ ਨਿਯਮ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ ਕਿ ਇੱਕ ਗੀਗਾਬਾਈਟ ਹਿਲਾਉਣ ਨਾਲ ਇੱਕ ਗੀਗਾਬਾਈਟ ਤਾਜ਼ਾ ਕਰਨਲ ਸ਼ੋਰ ਖਪਤ ਹੁੰਦਾ ਹੈ। ਦੋਵੇਂ ਇਸ ਵਿਚਾਰ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਕਿ ਕੁੰਜੀ ਬਣਾਉਣਾ ਅਤੇ ਹੈਂਡਸ਼ੇਕ ਹੀ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਬੀਜਣਾ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ।

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

ਉਡੀਕ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਦਿਸਦੀ ਹੈ

ਟਾਈਮਸਟੈਂਪ ਸੈਸ਼ਨ ਦੁਆਲੇ ਨਹੀਂ, ਪੜਾਵਾਂ ਦੁਆਲੇ ਲਗਾਓ: ਸ਼ੁਰੂਆਤ, ਪ੍ਰਮਾਣਿਕਤਾ, ਕੁੰਜੀ ਬਦਲਾਅ ਅਤੇ ਟ੍ਰਾਂਸਫਰ। ਟਨਲ ਵਰਤੋਂ ਯੋਗ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਉਡੀਕ ਘੱਟ ਸਥਿਰ ਦਰ ਨਾਲੋਂ ਵੱਖਰੀ ਸ਼ਿਕਾਇਤ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਬੇਤਰਤੀਬੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ। Linux ਵਿੱਚ ਆਮ getrandom() ਬੇਨਤੀ ਕਰਨਲ ਦੇ ਬੇਤਰਤੀਬ ਸਰੋਤ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੱਕ ਰੁਕ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਇਸ ਸਮੱਸਿਆ ਦਾ ਬੂਟ-ਸਮੇਂ ਵਾਲਾ ਰੂਪ ਸ਼ੁਰੂ ਵਿੱਚ ਤਲਾਬ ਨੂੰ ਖਵਾਉਣ ਲਈ ਥੋੜ੍ਹਾ ਹੀ ਰੱਖਣ ਵਾਲੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਅਤੇ ਐਂਬੈਡਿਡ ਬੋਰਡਾਂ ਤੇ ਅਸਲੀ ਹੈ।

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

cat /proc/sys/kernel/random/entropy_avail
uname -r

ਸੁਧਾਰ ਨੂੰ ਪੜ੍ਹਤ ਨਾਲ ਮਿਲਾਓ

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

ss -tin dst 203.0.113.7
sar -n DEV 1 5

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