VPN सर्वर का अपटाइम: यह संख्या आपको क्या नहीं बताती

सार्वजनिक नोड सूची हफ़्तों में मापे गए अपटाइम वाला सर्वर दिखाती है, इसलिए आप उसे चुनते हैं, और पहले ही प्रयास में कनेक्शन विफल हो जाता है। यह झूठा विज्ञापन नहीं है; यह किसी और चीज़ को मापने वाली संख्या से पूछा गया गलत प्रश्न है। अपटाइम आमतौर पर बताता है कि कोई प्रक्रिया, कंटेनर या मशीन अपने पिछले शुरू होने से कितने समय से चल रही है, और यह प्रकाशक के ढाँचे का गुण है, आपके वहाँ तक के मार्ग का नहीं। इसे विश्वसनीयता मानना वही श्रेणी-त्रुटि है जो कार के ओडोमीटर को सड़क की रिपोर्ट मानना है।

यह संख्या क्या मापती है

आधुनिक सेवा प्रबंधक वाले होस्ट पर, काउंटर किसी ऐसी घटना से जुड़ा होता है जिसे आप वास्तव में पढ़ सकते हैं: वह समय-चिह्न जब इकाई सक्रिय स्थिति में गई, या मशीन का बूट समय। बाकी सब उस लंगर पर गणित है, और लंगर की परिभाषा प्रकाशकों के बीच अलग होती है। एक सूची डीमन के पुनः आरंभ पर रीसेट हो सकती है, दूसरी मशीन के पुनः चालू होने पर, और तीसरी किसी ऐसे ऑपरेटर द्वारा किए गए मैन्युअल रीसेट पर जो साफ़ ग्राफ़ चाहता था।

systemctl show -p ActiveEnterTimestamp --value openvpn-server@server
uptime -s
systemctl is-active openvpn-server@server

वे तीन कमांड तीन अलग प्रश्नों का उत्तर देते हैं, और एक संख्या दिखाने वाली निर्देशिका सूची आपको नहीं बता सकती कि उसने उनमें से किसका उपयोग किया। इसलिए दो सूचियों के कच्चे काउंटर की तुलना तब तक कोई तुलना नहीं है जब तक आप यह न जानें कि प्रत्येक किस पर रीसेट होता है।

मार्ग ठप होने पर भी प्रक्रिया चल सकती है

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

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

उल्टा मामला भी याद रखने योग्य है। एक घंटा पहले पुनः आरंभ किया गया नोड अब पूरी तरह स्वस्थ हो सकता है, और सबसे बड़ी संख्या के अनुसार क्रमबद्ध करना उसे चुपचाप बाहर कर देता है। अपटाइम गुणवत्ता का स्कोर नहीं है, और उसे ऐसा मानना उपयुक्तता के बजाय उम्र के आधार पर चयन करता है।

ताज़गी: रिपोर्ट आपके प्रयास से पुरानी है

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

यह अंतराल दूसरी दिशा में भी काम करता है। बंद बताया गया नोड रिपोर्ट बनने के कुछ मिनट बाद ही ठीक हो सकता है, इसलिए किसी दूसरे नोड पर तुरंत पुनः प्रयास करना हमेशा बेहतर विकल्प नहीं है।

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

इसके बजाय क्या जाँचें

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

nc -vz -w 5 vpn.example.net 1194
curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' https://vpn.example.net/
mtr -rwc 20 vpn.example.net

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

धोखे में आए बिना सार्वजनिक नोड सूचियाँ पढ़ना

अपटाइम उन चीज़ों के बारे में भी कोई जानकारी नहीं देता जो लोग आमतौर पर VPN से चाहते हैं: प्रमाणपत्र की वैधता, निकास कौन चलाता है, कौन सी DNS नीति लागू होती है, और क्या ऑपरेटर कनेक्शन रिकॉर्ड रखता है। ये अलग-अलग दावे हैं जिनके लिए अलग-अलग साक्ष्य चाहिए, और लंबा काउंटर इनमें से किसी का साक्ष्य नहीं है। नोड महीनों तक स्थिर रह सकता है और फिर भी गोपनीयता की आवश्यकता के लिए खराब विकल्प हो सकता है।

सूची वास्तव में जहाँ मदद करती है वह छोटी सूची बनाने में है। जो आप जानते हैं कि आपको चाहिए उसके अनुसार क्रमबद्ध करें, कार्य से असंबंधित क्षेत्रों के नोड फ़िल्टर करें, फिर शेष तीन या चार को जाँचें। केवल हाँ या ना के बजाय हर प्रयास की विफलता का चरण रखें, क्योंकि «TLS हैंडशेक विफल» और «जुड़ा पर थ्रूपुट नहीं» पूरी तरह अलग निष्कर्षों तक ले जाते हैं।

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