माझा 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]*"

बोगदा वारंवार रीसेट होत असेल, तर कोणतीही थ्रूपुट संख्या समजून घेण्यापूर्वी तुटणे दुरुस्त करा, कारण पुन्हा जोडणारा बोगदा मार्ग नाही, हस्तांदोलन मोजतो। प्रत्येक बदलानंतर मूळ काम पुन्हा करा आणि निकाल जतन करा। वेगवान वेग चाचणी तरीही कॉल तोडत असेल तर तुम्ही ज्या तक्रारीने सुरुवात केली ती सुटली नाही।