VPN ની એન્ટ્રોપી ખતમ થઈ જાય છે? entropy_avail ખરેખર શું દર્શાવે છે

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

આ દંતકથા કેમ ટકે છે

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

આ જનરેટર આ રીતે કામ કરતા નથી. ક્રિપ્ટોગ્રાફિક લાઇબ્રેરી બીજવાળું જનરેટર રાખે છે અને તેમાંથી આઉટપુટ ખેંચે છે, પોતાની નીતિ મુજબ ફરી બીજ વાવે છે, તેથી મોંઘી ક્ષણ બીજ વાવવાની છે, સ્થિર સ્થાનાંતરણ નહીં.

જનરેટર પ્રતિ પેકેટ શું કરે છે

OpenSSL 3 માં ડિફોલ્ટ જનરેટર શ્રેણી DRBG ઉદાહરણોથી બને છે જે રૂપરેખાંકન અને સ્થિતિ મુજબ બીજ વાવે છે અને ફરી વાવે છે. OpenVPN 2.6 માં AEAD ડેટા માર્ગ પોતાનું nonce પેકેટના ક્રમ નંબરમાંથી પ્રતિ-સત્ર ગર્ભિત મૂલ્ય સાથે મેળવે છે, જ્યારે જૂનો CBC માર્ગ પ્રતિ પેકેટ સ્યુડો-રેન્ડમ IV ખેંચે છે. બંનેમાંથી કોઈ પણ પેટર્ન એ નિયમને સમર્થન આપતું નથી કે એક ગીગાબાઇટ ખસેડવાથી એક ગીગાબાઇટ તાજો કર્નલ અવાજ વપરાય છે. બંને એ વિચારને સમર્થન આપે છે કે કી જનરેશન અને હેન્ડશેક એ જ જગ્યા છે જ્યાં બીજ વાવવાનું મહત્ત્વ ધરાવે છે.

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

રાહ ખરેખર ક્યાં દેખાય છે

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

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

cat /proc/sys/kernel/random/entropy_avail
uname -r

વાંચન સાથે સુધારો મેળવો

જો કર્નલ ખરેખર ઇનિશિયલાઇઝેશનની રાહ જોતું હોય, તો ટનલ તરફ નહીં, પ્લેટફોર્મના સમર્થિત બીજ-વાવવાના માર્ગ તરફ જુઓ. વર્ચ્યુઅલ મશીનને હોસ્ટ દ્વારા પૂરું પાડવામાં આવેલું રેન્ડમ ઉપકરણ આપી શકાય, જેમ કે virtio-rng, અને ઇમેજની તૈયારી મહત્ત્વની છે કારણ કે ઘણા ગેસ્ટમાં અપરિવર્તિત રીતે કૉપિ કરેલું બીજ સ્વતંત્ર ઇનિશિયલાઇઝેશન નથી. જો લાઇબ્રેરી બૂટ પછી બીજ-વાવવાની નિષ્ફળતા જણાવે, તો કર્નલ સેટિંગ્સ બદલવાને બદલે તેનો રૂપરેખાંકિત સ્રોત અને પ્રદાતાનું વર્તન તપાસો.

ss -tin dst 203.0.113.7
sar -n DEV 1 5

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