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 விருப்பமில்லாத நிறுவல்களில் அதே முடிவைத் தருகிறது. sandbox ஐ விரிவாக்குவது, ஒவ்வொரு எழுத்துச் சாதனத்திற்கும் அணுகல் தருவது அல்லது 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'

அந்த வெளியீட்டில் இரண்டு தனித்தனி விஷயங்களைத் தேடுங்கள்: சீரற்ற மூலம் பற்றிய செய்தி மறைவது, மற்றும் சுரங்கப்பாதை அதன் வழக்கமான தொடக்க மைல்கல்லை அடைவது. மீண்டும் வேலை செய்யும் உருவாக்கி ஒரு உள்ளூர் தோல்வியை நீக்குகிறது, சேவையக அடையாளம், சான்றுகள் அல்லது வழித்தடம் பற்றி எதுவும் சொல்லாது. முன்பு தோல்வியடைந்த அதே வாடிக்கையாளர் உள்ளமைவுடன் இதைச் சோதியுங்கள், இதனால் முடிவு ஒப்பிடத்தக்கதாக இருக்கும், வெறும் சிறப்பாக அல்ல.