શું ઓછું VPN થ્રુપુટ એન્ટ્રોપીની સમસ્યા છે? સામાન્ય રીતે નહીં

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

સમાન દેખાતાં બે લક્ષણો

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

સ્ટાર્ટઅપ, પ્રમાણીકરણ, કી ફરીથી વાટાઘાટ અને ટ્રાન્સફરની આસપાસ ટાઇમસ્ટેમ્પ મૂકો. ટનલ વાપરી શકાય તે પહેલાંનો લાંબો વિલંબ નીચો સ્થિર દર નથી, અને બંનેની સરેરાશ એક સંખ્યામાં કરવાથી પુરાવો નષ્ટ થાય છે.

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

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

રેન્ડમ સંખ્યાઓની રાહ ખરેખર કેવી દેખાય છે

સુરક્ષિત રેન્ડમ બાઇટ્સની વિનંતી કર્નલ તેનો રેન્ડમ સ્રોત શરૂ કરે ત્યાં સુધી અવરોધિત થઈ શકે છે. આ સૌથી વધુ વર્ચ્યુઅલ મશીનો અને નાના એમ્બેડેડ બોર્ડ પર બૂટની શરૂઆતમાં મહત્વપૂર્ણ છે, જ્યારે થોડો પર્યાવરણીય ઘોંઘાટ એકઠો થયો હોય છે. એથી એમ નથી નીકળતું કે દરેક એન્ક્રિપ્ટેડ બાઇટ તાજી એન્ટ્રોપી વાપરે છે.

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

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

પહેલો આદેશ બતાવે છે કે તમે જોતાં હોય ત્યારે પ્રક્રિયા રેન્ડમ સંખ્યાના કૉલમાં બેઠી છે કે નહીં. બીજો કર્નલના પોતાના પ્રારંભિક સંદેશા બતાવે છે, અને ત્યાં જ વહેલા બૂટનું સ્થગન દેખાય છે.

કર્નલની આવૃત્તિ અને સેવા ખરેખર જે લાઇબ્રેરી સાથે લિંક થાય છે તે નોંધો, કારણ કે વર્તન અમલીકરણો અને આવૃત્તિઓ વચ્ચે અલગ પડે છે. રિકવરી પછી લેવાયેલો ટ્રેસ સામાન્ય રીતે વિરામને સંપૂર્ણ ચૂકી જાય છે.

સતત ધીમાપણું ખરેખર કેવું દેખાય છે

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

તુલનાત્મક આધારરેખા સાથે બંને દિશામાં માપો, અને એપ્લિકેશનના પોતાના અહેવાલને બદલે ઇન્ટરફેસ કાઉન્ટર જુઓ.

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

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

તમે માપેલા અવરોધ માટે સુધારો પસંદ કરો

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

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

ફેરફાર ફક્ત ત્યારે જ સ્વીકારો જ્યારે સમાન માપ સમાન પરિસ્થિતિઓમાં સુધરે. મોટું કાઉન્ટર પરિણામ નથી; ટૂંકી માપેલી રાહ અથવા ઓળખાયેલા કારણ સાથેનું ઝડપી ટ્રાન્સફર પરિણામ છે.