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'

ఆ అవుట్పుట్లో రెండు వేర్వేరు విషయాలను వెతకండి: రాండమ్ మూలం గురించిన సందేశం మాయమవడం, మరియు సొరంగం తన సాధారణ ప్రారంభ మైలురాయిని చేరుకోవడం. తిరిగి పనిచేసే జనరేటర్ ఒక స్థానిక వైఫల్యాన్ని తొలగిస్తుంది మరియు సర్వర్ గుర్తింపు, ఆధారాలు లేదా రూటింగ్ గురించి ఏమీ చెప్పదు. మునుపు విఫలమైన అదే క్లయింట్ కాన్ఫిగరేషన్తో దీన్ని పరీక్షించండి, తద్వారా ఫలితం పోల్చదగినదిగా ఉంటుంది, కేవలం మెరుగ్గా కాదు.