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

एउटा पियरका लागि लाइन र भीडको स्थिति पहिलो आदेशले देखाउँछ। दोस्रो र तेस्रोले स्ट्याक र इन्टरफेसमा ड्रप र पुनःप्रेषण रिपोर्ट गर्छन्, जहाँ कारण सामान्यतया पहिले देखिन्छ।

तपाईंले नापेको अवरोधका लागि सुधार छान्नुहोस्

प्रमाणले प्रारम्भिक बुट सुरुवाततर्फ संकेत गर्छ भने, प्लेटफर्मको समर्थित सिडिङ मार्ग हेर्नुहोस्, जसमा भर्चुअल मेसिनमा होस्टले उपलब्ध गराएको अनियमित उपकरण समावेश हुन सक्छ। धेरै गेस्टमा अपरिवर्तित रूपमा प्रतिलिपि गरिएको सिड छवि स्वतन्त्र सुरुवातको विकल्प होइन।

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

त्यही मापन त्यही परिस्थितिमा सुधार भएमा मात्र परिवर्तन स्वीकार गर्नुहोस्। ठूलो काउन्टर नतिजा होइन; छोटो नापिएको प्रतीक्षा वा पहिचान भएको कारणसहितको छिटो स्थानान्तरण नतिजा हो।