VPN निर्देशिका अपने पीछे के नोड की ज़मानत क्यों नहीं ले सकती
एक प्रविष्टि किसी कनेक्शन का और उसे प्रकाशित करने वाली निर्देशिका का वर्णन करती है। संग्रह और प्रतिधारण ऑपरेटर के पास है, जो कोई दूसरा पक्ष हो सकता है।
निर्देशिका की जो प्रविष्टियाँ होस्टनाम, देश और प्रोटोकॉल का एक समूह सूचीबद्ध करती हैं, वे कनेक्टिविटी के प्रमाण हैं, यह नहीं कि दूसरे छोर की मशीन क्या दर्ज करती है। यहाँ महत्वपूर्ण निर्णय यह नहीं है कि सूचियों पर आम तौर पर भरोसा करना चाहिए या नहीं। यह है कि कौन-सा पक्ष उस प्रश्न का उत्तर देने की स्थिति में है जो आप वास्तव में पूछ रहे हैं।
एक प्रविष्टि के पीछे चार पक्ष
कोई भी वादा पढ़ने से पहले भूमिकाएँ अलग करें। निर्देशिका प्रविष्टि प्रकाशित करती है, सॉफ़्टवेयर परियोजना प्रोटोकॉल का कार्यान्वयन देती है, होस्टिंग प्रदाता मशीन और नेटवर्क देता है, और नोड ऑपरेटर सेवा को कॉन्फ़िगर करता है। चारों में से कोई भी अलग संगठन हो सकता है, और हर एक केवल अपने हिस्से के लिए बोल सकता है।
यही विभाजन बताता है कि कोई कथन सत्य होकर भी निष्प्रयोजन क्यों हो सकता है। जो डेवलपर दर्ज करता है कि प्रोटोकॉल पेलोड दर्ज नहीं करता, वह ऐसे ऑपरेटर के बारे में कुछ नहीं कहता जिसने रिले पर विस्तृत कनेक्शन लॉगिंग सक्षम की है। दोनों कथन बिना विरोधाभास के साथ रह सकते हैं। इसी कारण प्रश्न किसी नामित पक्ष से पूछा जाना चाहिए।
कुछ सेवाएँ अपने अंतिम बिंदु स्वयं चलाती हैं, और तब प्रविष्टि और नीति एक ही पक्ष से आती हैं। यह अधिक मज़बूत स्थिति है, पर इसे अभी भी सिद्ध करना होता है, पृष्ठ के स्वरूप से मान लेना नहीं। बयान माँगिए, और जाँचिए कि वह उस सेवा का नाम लेता है जिसकी ओर प्रविष्टि संकेत करती है।
दावे से मेल खाने वाला अभिलेख माँगिए
संग्रह के दावे के लिए ऐसा दस्तावेज़ चाहिए जो सिस्टम, डेटा श्रेणी और अवधि का नाम ले। प्रतिधारण के दावे के लिए एक संख्या और विस्तार चाहिए। स्वतंत्रता के दावे के लिए विवरण चाहिए कि कौन क्या रखता है, विशेषण नहीं।
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
स्वयंसेवी परियोजनाएँ अक्सर सबसे स्पष्ट उदाहरण होती हैं, क्योंकि कुछ अपने स्वीकार किए गए नोड के लिए स्पष्ट लॉगिंग आवश्यकताएँ प्रकाशित करती हैं। वह दस्तावेज़ परियोजना के नियमों पर प्राथमिक प्रमाण है, और वह अब भी किसी ऐसे व्यक्तिगत ऑपरेटर के बारे में प्रमाण नहीं है जिसने उन्हें अनदेखा किया।
लेखा-परीक्षाएँ दूसरे पैमाने पर उसी तर्क का पालन करती हैं। जो रिपोर्ट किसी विशेष परिनियोजन की जाँच किसी विशेष अवधि में करती है, वह उस सीमा के भीतर उपयोगी है। उसी सॉफ़्टवेयर के हर स्वतंत्र प्रतिरूप पर फैलाई जाए तो वह ऐसी गारंटी बन जाती है जो किसी ने नहीं दी। निष्कर्ष पढ़ने से पहले विस्तार वाला अनुच्छेद पढ़ें।
जब किसी विक्रेता का गोपनीयता कथन उसकी अपनी सेवा को आवृत करता है, तो उसे उस विक्रेता का अपने ही सिस्टमों के बारे में कथन मानकर पढ़ें। तीसरे पक्ष के रिले का वर्णन करने के लिए उसका पुनः उपयोग श्रेणीगत भूल है, प्रोटोकॉल एक जैसा होने पर भी।
तय कीजिए कि हर विकल्प के साथ आप क्या खरीदते हैं
सार्वजनिक नोड जवाबदेही की कीमत पर पहुँच और विविधता खरीदता है। जो ऑपरेटर आपका कोई ऋणी नहीं है, वह गायब हो सकता है, कॉन्फ़िगरेशन बदल सकता है या बिना सूचना के अभिलेख रख सकता है, और आपका उपाय केवल इतने तक सीमित है: अंतिम बिंदु बदलना। यह अदला-बदली कुछ कार्यों के लिए स्वीकार्य है और कुछ के लिए नहीं।
भुगतान वाली सेवा प्रकाशित नीति और खोने के लिए कुछ रखने वाले प्रतिपक्ष को खरीदती है। वह तकनीकी गारंटी नहीं खरीदती और नीति पढ़ने की आवश्यकता नहीं हटाती, पर प्रतिधारण कथन वाला नामित संगठन अनाम रिले की तुलना में आसानी से आँका जा सकता है।
दोनों स्थितियों में टिकने वाला निर्णय-नियम यह है कि प्रमाण को जोखिम से मिलाएँ। यदि कार्य बदलते अंतिम बिंदु को सह लेता है, तो निर्देशिका एक कुशल साधन है। यदि वह डेटा प्रबंधन के किसी विशेष वादे पर निर्भर है, तो केवल वही पक्ष प्रासंगिक है जो वह वादा कर सकता है, और निर्देशिका मार्ग-निर्देश की सुविधा है, आश्वासन नहीं।
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'ऊपर दिया गया एक आदेश चलाने योग्य है, क्योंकि वह दो प्रश्नों को स्पष्ट रूप से अलग करता है। वह वह पता दिखाता है जो आपके ट्रैफ़िक ने वास्तव में इस्तेमाल किया, जो कनेक्टिविटी का तथ्य है, और वह इस बारे में कुछ नहीं कहता कि उस पते के ऑपरेटर ने कनेक्शन के मेटाडेटा के साथ क्या किया।
क्लाइंट पक्ष के प्रश्न अलग रखें
ऑपरेटर की नीति एक परत है, और सुरंग के भीतर आप जो करते हैं उसकी सुरक्षा दूसरी है। गंतव्य पर HTTPS, ब्राउज़र में सत्र प्रबंधन और जिस खाते में आपने प्रवेश किया उसकी मज़बूती आपके नियंत्रण बने रहते हैं, और उदार रिले उन्हें कमज़ोर नहीं करता जैसे उत्कृष्ट रिले उन्हें मज़बूत नहीं करता।
यह विभाजन दो सामान्य भूलों को रोकता है। कठोर ऑपरेटर नीति को HTTPS छोड़ने का कारण मानना एक है, और काम करने वाले HTTPS कनेक्शन को यह अनदेखा करने का कारण मानना कि रिले कौन चलाता है दूसरी है। दोनों भूलें दो परतों को एक में मिला देती हैं और फिर गलत परत पर बहस करती हैं।
एक संक्षिप्त लिखित मूल्यांकन दोनों सँभालता है। हर वादा देने वाले पक्ष का नाम लें, उसका समर्थन करने वाला दस्तावेज़ संलग्न करें और तारीख़ नोट करें। फिर तय करें कि कार्य को मज़बूत दावा चाहिए या केवल एक काम करने वाला मार्ग।
प्रविष्टि ने अपना काम तब किया जब उसने बताया कि आप कहाँ जुड़ सकते हैं। प्रश्न का शेष भाग उस व्यक्ति का है जो वह अंतिम बिंदु चलाता है, और ईमानदार उत्तर अक्सर यह होता है कि आप जान नहीं सकते और उसी के अनुसार चुनना चाहिए।