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'

તે આઉટપુટમાં બે અલગ વસ્તુઓ શોધો: રેન્ડમ સ્રોતનો સંદેશ અદૃશ્ય થવો, અને ટનલ તેના સામાન્ય પ્રારંભિક તબક્કે પહોંચવું. ફરી કામ કરતું જનરેટર એક સ્થાનિક નિષ્ફળતા દૂર કરે છે અને સર્વરની ઓળખ, ઓળખપત્રો અથવા રૂટિંગ વિશે કંઈ કહેતું નથી. તે જ ક્લાઇન્ટ રૂપરેખાંકન સાથે આનું પરીક્ષણ કરો જે પહેલાં નિષ્ફળ ગયું હતું, જેથી પરિણામ તુલનાત્મક હોય અને ફક્ત સારું નહીં.