आपका सर्वर VPN एग्ज़िट देखता है, आगंतुक को नहीं
VPN उस स्रोत पते को बदल देता है जिसे कोई सेवा देखती है। पता-श्रेणियाँ, विलंब और एडाप्टर नाम VPN उपयोग के बारे में अनुमान हैं, इस बात का प्रमाण नहीं कि कौन जुड़ा।
एक आगंतुक वाणिज्यिक VPN से जुड़ता है और आपका एप्लिकेशन एग्ज़िट पता लॉग करता है। यह छिपी पहचान नहीं है: यह वही एकमात्र स्रोत पता है जो TCP कनेक्शन के पास है। बाकी सब जिसे लोग पहचान कहते हैं, उसी एक तथ्य पर चढ़ाया गया अनुमान है।
कोई अनुरोध वास्तव में क्या ले जाता है
एप्लिकेशन कनेक्शन का स्रोत पता और पोर्ट, पूरा हुआ हैंडशेक और वे बाइट देखता है जो क्लाइंट ने भेजने के लिए चुने। पूर्ण टनल के अंतर्गत वह स्रोत एग्ज़िट है, जो इसका उपयोग करने वाले सभी लोगों में साझा है। विभाजित टनल के अंतर्गत अनुरोध गंतव्य के अनुसार टनल से या स्थानीय कनेक्शन से आ सकते हैं। यदि क्लाइंट और सर्वर दोनों एक ही VPN के भीतर हैं, तो स्रोत क्लाइंट का आंतरिक टनल पता है, जो स्थान के बजाय एक अंतिम बिंदु की पहचान करता है।
सामान्य अनुरोध का कोई भी फ़ील्ड वह पता नहीं ले जाता जो क्लाइंट के पास टनल से पहले था। फ़ॉरवर्डिंग हेडर क्लाइंट या किसी प्रॉक्सी का दावा है, और इसे छोड़ा या जाली बनाया जा सकता है।
पहचान वर्गीकरण है, और वर्गीकरण एक अनुमान है
व्यावहारिक तरीके हैं ज्ञात VPN और होस्टिंग श्रेणियों की सूचियाँ, दावा किए गए क्षेत्र से मेल न खाने वाला विलंब, traceroute के आकार और खाते का व्यवहार। इनमें से हर एक संभावना उत्पन्न करता है। कॉर्पोरेट VPN ऐसे पतों पर हो सकता है जो आवासीय लगते हैं, आवासीय प्रॉक्सी घरेलू लाइन जैसा लग सकता है, और कैरियर NAT होस्टिंग श्रेणी जैसा लग सकता है।
साझा एग्ज़िट को अवरुद्ध करना उसके पीछे के हर असंबंधित उपयोगकर्ता को अवरुद्ध करता है, जो पहचान के निर्णय को एक पार्श्विक व्यवधान में बदल देता है। विश्वास स्कोर पहचान नहीं है और उसे कभी भी प्रतिबंध या रिफ़ंड के निर्णय का एकमात्र इनपुट नहीं होना चाहिए।
यदि VPN आपका है, तो आपके पास एक विश्वसनीय संकेत है जिसका पहचान से कोई संबंध नहीं है: एक समर्पित पूल निर्धारित करें और देखे गए स्रोत को उससे मिलाएँ। यह काम करता है क्योंकि आप दोनों सिरों को नियंत्रित करते हैं और पूल का दस्तावेज़ीकरण कर सकते हैं। लेकिन यह उन आगंतुकों तक सामान्यीकृत नहीं होता जिन्हें आप प्रबंधित नहीं करते, और जिस क्षण पूल अन्य सेवाओं के साथ साझा होता है वह विश्वसनीय रहना बंद कर देता है।
स्थानीय साक्ष्य बनाम सर्वर-पक्षीय प्रमाण
मशीन पर ही टनल दिखाई देती है: एक वर्चुअल एडाप्टर, टनल डिवाइस की ओर इशारा करने वाला डिफ़ॉल्ट रूट, बदला हुआ रिज़ॉल्वर। वहाँ चलने वाला कोड इंटरफ़ेस गिन सकता है और PPP, TAP या विक्रेता ड्राइवर खोज सकता है।
कोई वेब पेज इनमें से कुछ भी नहीं पढ़ सकता। सामान्य उपाय केवल आंतरिक नेटवर्क से दिया गया एक संसाधन लोड करता है और सफलता को टनल उपयोग का प्रमाण मानता है। वह वास्तव में पहुँच परखता है: विभाजित टनल, पुरानी कैश की गई फ़ाइल या इंटरसेप्शन प्रॉक्सी दोनों स्थितियों में वही परिणाम देते हैं। स्थानीय साक्ष्य स्थानीय ही रहते हैं।
ऐसे पहुँच नियंत्रण चुनें जो अस्पष्टता झेल सकें
पहुँच नियंत्रण को सत्यापित पहचान, डिवाइस की सेहत और प्रति-संसाधन अधिकृति पर बनाएँ। ये विधेय बताते हैं कि कौन पूछ रहा है और वह कहाँ तक पहुँच सकता है, और टनल शामिल हो या न हो वे अर्थपूर्ण रहते हैं। क्या कोई अनुरोध VPN से आया, यह एक कमज़ोर संकेत है जो झूठी स्वीकृतियाँ और पार्श्विक अवरोध दोनों पैदा करता है। साक्ष्य और निर्णय को अलग-अलग फ़ील्ड में रखें, ताकि विवादित अवरोध के पास समीक्षा के लिए कुछ हो।
IP भू-स्थान कई इनपुट में से एक है, और ब्राउज़र की स्थान सेवाएँ Wi-Fi या GPS का उपयोग कर सकती हैं जो कभी टनल का अनुसरण नहीं करते। जो नक्शा अब भी आगंतुक का शहर दिखाता है वह स्थान सेवाओं के बारे में साक्ष्य है, टनल विफल होने का प्रमाण नहीं।
लिखें कि किस संकेत ने कौन-सा निर्णय चलाया। जब कोई ग्राहक अवरोध का विरोध करता है, तो वही रिकॉर्ड समीक्षा और बहस के बीच का अंतर है।