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 जोडणीला रिले कोण चालवतो हे दुर्लक्ष करण्याचे कारण मानणे ही दुसरी. दोन्ही चुका दोन स्तरांचे एक करतात आणि मग चुकीच्या स्तराबद्दल वाद घालतात.
थोडक्यात लिखित मूल्यांकन दोन्ही सांभाळते. प्रत्येक वचन देणाऱ्या पक्षाचे नाव घ्या, त्याला आधार देणारा दस्तऐवज जोडा, आणि तारीख नोंदवा. मग कामाला अधिक मजबूत दावा हवा आहे की फक्त चालणारा मार्ग, हे ठरवा.
नोंदीने तिचे काम तेव्हा केले जेव्हा तिने तुम्हाला सांगितले की तुम्ही कुठे जोडले जाऊ शकता. प्रश्नाचा उर्वरित भाग तो अंतिम बिंदू चालवणाऱ्याचा आहे, आणि प्रामाणिक उत्तर बहुतेक वेळा असे असते की तुम्ही हे जाणू शकत नाही आणि त्यानुसार निवडले पाहिजे.