मेरा VPN इतना धीमा क्यों है? ये चार हिस्से जाँचें

बार-बार रुकने वाली कॉल, रेंगती हुई डाउनलोड और आधे रास्ते पर जम जाने वाली अपलोड — एक ही लेबल के नीचे तीन अलग शिकायतें हैं। कुछ भी मापने से पहले यह तय करना कि आप किसका पीछा कर रहे हैं, बाकी जाँच बचा लेता है। इसके बाद एक बार में रास्ते का एक हिस्सा बदलें और उसी काम को दोबारा करें।

नीचे दिया गया क्रम काम से बाहर की ओर बढ़ता है, क्योंकि टनल उस बैंडविड्थ को नहीं दे सकती जो उसके नीचे कम है।

मापने से पहले तय करें कि धीमा का क्या मतलब है

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

उस रिकॉर्ड के बिना, हर बाद की तुलना धारणाओं पर बहस बन जाती है।

पहले एक्सेस नेटवर्क जाँचें

अपने बड़े ट्रांसफर रोकें, फिर टनल शामिल होने से पहले स्थानीय लिंक मापें। किसी हानिरहित काम से तुलना करें और एक साथ कई सुरक्षाएँ बंद करने के बजाय क्लाइंट की kill switch प्रक्रिया अपनाएँ, और दोनों रन के लिए वही गंतव्य रखें। स्पीड-टेस्ट प्रदाता आपके दिखने वाले स्थान के बदलते ही आपको अलग मापन सर्वर दे सकता है, जिससे तुलना दो अलग सर्वरों की परीक्षा बन जाती है।

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

अगर बेसलाइन पहले से खराब है, तो काम Wi-Fi, राउटर की मांग या एक्सेस सेवा का है। तार वाली जाँच या एक्सेस पॉइंट के पास स्थिर स्थिति कमजोर रेडियो लिंक को भीड़भाड़ वाली अपलिंक से अलग करती है। टनल जो भी करे, वह उस क्षमता को नहीं जोड़ेगी जो एक्सेस लाइन नहीं दे रही है।

एग्ज़िट बदलें, फिर ट्रांसपोर्ट

डिवाइस, नेटवर्क और प्रोटोकॉल को स्थिर रखें और दूसरा एंडपॉइंट जाँचें। स्थान सूची से कोई विश्वसनीय शहर चुनें, लेकिन यह न मानें कि सबसे करीबी लेबल का मतलब सबसे अच्छा रास्ता है। अगर एक एग्ज़िट धीमा है और बाकी ठीक हैं, तो उसका होस्ट या रास्ता जाँच के लायक है; अगर एक डिवाइस पर सभी एग्ज़िट धीमे हैं जबकि दूसरा डिवाइस ठीक है, तो क्लाइंट अधिक संदिग्ध है।

जहाँ सेवा दोनों प्रोफ़ाइल देती है, वहाँ UDP पर OpenVPN की तुलना TCP पर OpenVPN से करें। इंटरैक्टिव काम के लिए UDP सामान्य शुरुआती बिंदु है, जबकि TCP ऐसे एक्सेस नेटवर्क पर मदद कर सकता है जो UDP ट्रैफ़िक बिल्कुल पार नहीं करता। TCP टनल स्ट्रीम के अंदर दोबारा भेजकर नुकसान की भरपाई करती है, इसलिए पैकेट गिराने वाले लिंक पर वह धीमी लग सकती है, और OpenVPN प्रदर्शन समस्या-निवारण के नोट कुछ और ट्यून करने से पहले उसी समझौते को समझाते हैं। प्रोफ़ाइल में "udp" शब्द को "tcp" में बदलने से ऐसा श्रोता नहीं बनता जिसे सर्वर ने कभी खोला ही न हो।

अगला बदलाव आज़माने से पहले वह प्रोफ़ाइल सहेजें जो मदद करती है। वरना बाद का कोई गिरावट आपको अंदाज़ा लगाने पर छोड़ देती है कि किस संपादन ने सुधार लाया।

डिवाइस और लक्षण को साथ पढ़ें

ट्रांसफर के बाद नहीं, उसके दौरान प्रोसेसर का भार देखें, क्योंकि एन्क्रिप्शन की लागत ट्रैफ़िक के साथ बढ़ती है और परिवार की सेवा करने वाला छोटा राउटर अपना क्लाइंट चलाने वाले लैपटॉप से अलग मशीन है। दूसरा VPN, वर्चुअल मशीन या नेटवर्क फ़िल्टर उसी रास्ते में बैठकर ट्रैफ़िक का हिस्सा ले सकते हैं। बेंचमार्क बेहतर दिखे इसके लिए प्रमाणीकरण जाँच या kill switch हटाए बिना सॉफ़्टवेयर अद्यतन रखें। अगर छोटे अनुरोध सफल हों और बड़ी अपलोड एक समान आकार पर अटकें, तो MTU जाँच अगला पड़ाव है।

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

जब टनल बार-बार रीसेट हो, तो किसी भी थ्रूपुट आंकड़े की व्याख्या से पहले डिस्कनेक्शन ठीक करें, क्योंकि फिर से जुड़ने वाली टनल रास्ते को नहीं, हैंडशेक को मापती है। हर बदलाव के बाद मूल काम दोहराएँ और परिणाम रखें। तेज़ स्पीड टेस्ट जो अब भी कॉल तोड़े, उस शिकायत को हल नहीं किया जिससे आपने शुरू किया था।