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'

ಆ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಎರಡು ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳನ್ನು ಹುಡುಕಿ: ಯಾದೃಚ್ಛಿಕ ಮೂಲದ ಸಂದೇಶ ಮಾಯವಾಗುವುದು, ಮತ್ತು ಸುರಂಗವು ತನ್ನ ಸಾಮಾನ್ಯ ಆರಂಭಿಕ ಹಂತವನ್ನು ತಲುಪುವುದು. ಮತ್ತೆ ಕೆಲಸ ಮಾಡುವ ಜನರೇಟರ್ ಒಂದು ಸ್ಥಳೀಯ ವೈಫಲ್ಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್ ಗುರುತು, ರುಜುವಾತುಗಳು ಅಥವಾ ರೂಟಿಂಗ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಹಿಂದೆ ವಿಫಲವಾದ ಅದೇ ಕ್ಲೈಂಟ್ ಸಂರಚನೆಯೊಂದಿಗೆ ಇದನ್ನು ಪರೀಕ್ಷಿಸಿ, ಇದರಿಂದ ಫಲಿತಾಂಶ ಹೋಲಿಸಬಹುದಾದದ್ದಾಗಿರುತ್ತದೆ, ಕೇವಲ ಉತ್ತಮವಲ್ಲ.