OpenVPN ਵਿੱਚ RAND_bytes ਅਸਫਲ: ਲਾਇਬ੍ਰੇਰੀ ਗਲਤੀ ਜਾਂ ਗੁੰਮ ਨੋਡ

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

ਵਾਪਸੀ ਮੁੱਲ ਕੀ ਵੱਖ ਕਰਦਾ ਹੈ

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

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

ਜਦੋਂ ਲੁਕਿਆ ਡਿਵਾਈਸ ਨੋਡ ਅਸਲ ਕਾਰਨ ਹੋਵੇ

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

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

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

ਪਹਿਲਾਂ ਗਲਤੀਆਂ ਦੀ ਕਤਾਰ ਪੜ੍ਹੋ, ਫਿਰ ਪ੍ਰਕਿਰਿਆ ਦਾ ਦ੍ਰਿਸ਼

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

openssl version -a
systemctl show openvpn-server@lab -p MainPID -p PrivateDevices -p DevicePolicy
pid=$(systemctl show -p MainPID --value openvpn-server@lab)
sudo ls -l /proc/"$pid"/root/dev/urandom /proc/"$pid"/root/dev/random

ਇਹ ਪੜ੍ਹਤਾਂ ਉਸੇ ਪ੍ਰਕਿਰਿਆ ਉੱਤੇ ਕਰੋ, ਸੰਜੋਗ ਨਾਲ ਖੁੱਲ੍ਹੇ ਸ਼ੈੱਲ ਉੱਤੇ ਨਹੀਂ। ਮੇਜ਼ਬਾਨ ਦੇ /dev ਦੀ ਤੁਲਨਾ ਅਸੰਬੰਧਿਤ ਪ੍ਰਕਿਰਿਆ ਦੇ ਦ੍ਰਿਸ਼ ਨਾਲ ਕਰਨਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਗਲਤ ਨਿਰਭਰਤਾ ਦੋ ਵਾਰ ਠੀਕ ਹੁੰਦੀ ਹੈ।

ਨਿਰਭਰਤਾ ਸਿਰਫ਼ ਤਦ ਜੋੜੋ ਜਦੋਂ ਤੁਸੀਂ ਇਸਦਾ ਨਾਮ ਦੇ ਸਕੋ

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

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

ਜਨਰੇਟਰ ਅਤੇ ਸੁਰੰਗ ਵੱਖਰੇ ਤੌਰ ਉੱਤੇ ਪਰਖੋ

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

sudo systemctl restart openvpn-server@lab
sudo journalctl -u openvpn-server@lab --since -5min --no-pager | grep -iE 'rand|entropy|Initialization Sequence'

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