क्या कम 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'

पहला कमांड एक साथी के लिए कतार और भीड़ की स्थिति दिखाता है। दूसरा और तीसरा स्टैक और इंटरफ़ेस पर ड्रॉप और पुनःप्रेषण की रिपोर्ट करते हैं, जहाँ कारण आमतौर पर पहले दिखता है।

आपने जो अवरोध मापा उसके लिए सुधार चुनें

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

यदि सबूत डेटा पथ की ओर इशारा करते हैं, तो जो काउंटर इंगित करते हैं उसे ट्यून करें। जब कतारें उछलती हैं तो बफ़र आकार मदद करते हैं और जब एक थ्रेड संतृप्त होता है तो कुछ नहीं करते। काउंटर बढ़ाने के लिए एंट्रॉपी डेमन स्थापित करना थ्रूपुट की मरम्मत नहीं है, और ग्राफ़ को बेहतर दिखाने के लिए सीडिंग मान्यताएँ बदलना सुरक्षा गुण के बदले एक संख्या खरीदना है।

परिवर्तन केवल तब स्वीकारें जब वही माप उन्हीं परिस्थितियों में सुधरे। बड़ा काउंटर परिणाम नहीं है; छोटा मापा गया इंतज़ार या पहचाने गए कारण के साथ तेज़ स्थानांतरण परिणाम है।