VPN पर Monero: तीन नेटवर्क पथों में से कौन-सा बदलता है?

वॉलेट खोलें, डेमन शुरू करें और कुछ भी सक्षम करने से पहले तीन तीर खींचें। एक तीर वॉलेट से किसी नोड के RPC पोर्ट तक जाता है, एक डेमन के पीयर सिंक्रोनाइज़ेशन को ढोता है, और एक स्थानीय रूप से भेजे गए लेन-देन को रिले पथ की ओर ले जाता है। ये अलग-अलग कॉन्फ़िगरेशन वाले अलग कनेक्शन हैं, और कोई VPN या अनामता नेटवर्क इनमें से एक, दो या किसी को भी नहीं ढक सकता।

पथों पर उसी क्रम में चलें जिस क्रम में सॉफ़्टवेयर उन्हें खोलता है। हर तीर को उसके गंतव्य और परिवहन के साथ लेबल करना ही बाद के गोपनीयता दावे को जाँचने योग्य बनाता है। क्रम मायने रखता है, क्योंकि बाद का दावा आमतौर पर इनमें से केवल एक को ढकता है।

वॉलेट-से-नोड कनेक्शन खींचकर शुरू करें

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

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

यहीं एक सार्वजनिक RPC एंडपॉइंट लुभावना हो जाता है। आरेख को सरल बनाने के लिए नोड की RPC सेवा को खोलना नेटवर्क पथ के बदले हमले की सतह देता है। वॉलेट-से-नोड लिंक को निजी पथ या लूपबैक इंटरफ़ेस पर रखें, और दर्ज करें कि कौन-सा है। जो आरेख उस खुलाव को छिपाता है वह आरेख न होने से बुरा है।

इसके बाद डेमन के पीयर ट्रैफ़िक का पीछा करें

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

पीयर पोर्ट, कनेक्शनों की संख्या और यह दर्ज करें कि डेमन पीयर ट्रैफ़िक के लिए प्रॉक्सी का उपयोग करने के लिए कॉन्फ़िगर है या नहीं। फिर किसी नमूना पीयर पते के लिए होस्ट रूट देखें। अगर VPN डिफ़ॉल्ट रूट को पकड़ लेता है, तो पीयर कनेक्शन संभवतः उसी का उपयोग करते हैं; अगर डेमन किसी विशेष इंटरफ़ेस से बँधा है, तो शायद नहीं। यही दो तथ्य तीर तय करते हैं।

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

फिर लेन-देन रिले पथ को अलग करें

स्थानीय रूप से भेजे गए लेन-देन को कॉन्फ़िगर किए गए रिले या प्रॉक्सी के माध्यम से नेटवर्क की ओर अग्रेषित किया जा सकता है। Monero डेमन के वर्तमान दस्तावेज़ में, वह विकल्प केवल उसी लेन-देन-रिले ट्रैफ़िक को प्रॉक्सी से भेजता है जिसे आप उसकी ओर निर्दिष्ट करते हैं। यह हर RPC, वॉलेट और सिंक्रोनाइज़ेशन कनेक्शन को प्रॉक्सी वाले ट्रैफ़िक में नहीं बदलता।

परियोजना का अनामता-नेटवर्क दस्तावेज़ Tor और I2P एकीकरण को प्रयोगात्मक बताता है और रिले व्यवहार का दायरा तय करता है। उसी संस्करण का दस्तावेज़ पढ़ें जो आप वास्तव में चलाते हैं, क्योंकि पुरानी चर्चाएँ Kovri जैसे नामों का उपयोग करती हैं और ऐसे घटकों का वर्णन करती हैं जो अब उसी रूप में मौजूद नहीं हैं।

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

तीनों पथों को लेबल करने के बाद ही VPN जोड़ें

तीर खींचे जाने के बाद, चिह्नित करें कि VPN वास्तव में किन्हें ढोता है। फ़ुल-टनल VPN होस्ट के डिफ़ॉल्ट रूट को पकड़ लेता है, इसलिए डिफ़ॉल्ट का पालन करने वाले कनेक्शन उसी का उपयोग करेंगे। स्प्लिट टनल, बँधा इंटरफ़ेस या किसी विशेष पते से बाहर जाने वाली प्रॉक्सी कुछ तीरों को टनल के बाहर छोड़ सकते हैं।

अब प्रेक्षक मॉडल स्पष्ट रूप से बताएँ। ऐसी रचना में जहाँ अनामता-नेटवर्क कनेक्शन VPN के भीतर चलता है, स्थानीय एक्सेस नेटवर्क बाहरी VPN कनेक्शन देखता है, जबकि VPN पक्ष आगे का कनेक्शन देखता है। यह प्रेक्षक का बदलाव है, पहचानने योग्य संकेतों के गायब होने का प्रमाण नहीं।

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

उन पथों को सत्यापित करें जिन्हें आपने कॉन्फ़िगर किया समझते हैं

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

VPN के फिर से कनेक्ट होने के बाद और डेमन के पुनः आरंभ के बाद दोहराएँ। गंतव्यों और परिवहनों की आरेख से तुलना करें। अगर कोई तीर हिला है, तो गोपनीयता मॉडल भी उसके साथ हिला है, भले ही हर प्रक्रिया अब भी स्वस्थ होने की सूचना दे।

तीनों गंतव्य, हर एक का परिवहन और वह प्रेक्षक दर्ज करें जिससे आप उन्हें छिपाना चाहते हैं। एक ही मशीन पर कई स्वतंत्र क्लाइंट चलने पर नामित प्रेक्षकों वाला छोटा पथ-नक्शा एकल VPN संकेतक से अधिक उपयोगी होता है।