कमी 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'

एका पीअरसाठी रांग आणि गर्दीची स्थिती पहिला आदेश दाखवतो। दुसरा आणि तिसरा स्टॅक आणि इंटरफेसवरील ड्रॉप आणि पुनःप्रेषण नोंदवतात, जिथे कारण सामान्यतः पहिल्यांदा दिसते।

तुम्ही मोजलेल्या अडथळ्यासाठी दुरुस्ती निवडा

पुरावा सुरुवातीच्या बूट आरंभाकडे निर्देश करत असल्यास, प्लॅटफॉर्मला समर्थित सीडिंग मार्ग पाहा, ज्यात व्हर्च्युअल मशीनवर होस्टने पुरवलेले यादृच्छिक उपकरण असू शकते। अनेक गेस्टमध्ये अपरिवर्तितपणे कॉपी केलेली सीड प्रतिमा स्वतंत्र आरंभाचा पर्याय नाही।

पुरावा डेटा मार्गाकडे निर्देश करत असल्यास, काउंटर जे सुचवतात ते ट्यून करा। रांगा ओसंडल्यावर बफर आकार मदत करतात आणि एक थ्रेड संतृप्त असताना काहीही करत नाहीत। काउंटर वाढवण्यासाठी एंट्रोपी डेमन स्थापित करणे ही थ्रूपुटची दुरुस्ती नाही, आणि आलेख चांगला दिसावा म्हणून सीडिंग गृहीतके बदलणे हे सुरक्षा गुणधर्माची संख्येशी देवाणघेवाण करणे आहे।

तोच मापन त्याच परिस्थितीत सुधारले तरच बदल स्वीकारा। मोठा काउंटर निकाल नाही; कमी मोजलेली प्रतीक्षा किंवा ओळखल्या गेलेल्या कारणासह वेगवान स्थानांतरण हा निकाल आहे।