क्या Tor VPN से होकर जाता है? स्प्लिट टनलिंग क्या बदलती है

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

कनेक्टेड बैज क्या साबित करता है, और क्या नहीं

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

यह अंतर किसी भी औज़ार में बग नहीं है। बहिष्करण नियम ठीक इसी के लिए है, और नियम शायद किसी ऐसे कारण से लिखा गया जो किसी को अब भी याद है।

क्लाइंट किसी कनेक्शन पर कौन-सा मैचर लागू करता है

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

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

टनल गिरने पर Tor के साथ क्या होता है

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

क्लाइंट का प्रलेखित व्यवहार भी पढ़ें, लेकिन दस्तावेज़ को तब तक परिकल्पना मानें जब तक आपकी परख उससे सहमत न हो। विक्रेता डिफ़ॉल्ट बताते हैं; आपकी प्रोफ़ाइल अपवाद तय करती है।

निकास पता प्रवेश का सवाल क्यों नहीं बता सकता

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

दो अलग रास्ते एक ही निकास देश दे सकते हैं, इसलिए मेल खाता परिणाम दिखने से भी कम साबित करता है। इंटरफ़ेस की तुलना करें, भूगोल की नहीं।

वे ऐप्स जिन्होंने कभी ब्राउज़र की सेटिंग्स विरासत में नहीं लीं

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

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