Tor के ज़रिए VPN: पहले ट्रांसपोर्ट की जाँच

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

जाँचों को क्रम से करें। हर एक तय करती है कि अगली शुरू करने लायक है या नहीं।

आप वास्तव में कौन-सा क्रम बना रहे हैं

एक ही बातचीत में दो क्रम उलझ जाते हैं। Tor पहले का अर्थ है कि VPN क्लाइंट SOCKS प्रॉक्सी से अपने सर्वर तक पहुँचता है, इसलिए सुरंग Tor के ऊपर बनती है। VPN पहले का अर्थ है कि Tor का ट्रैफ़िक सुरंग से बाहर जाता है, जिसे अधिकांश लोग गलती से बनाते हैं और फिर दूसरा क्रम कहकर बताते हैं। पहला अग्रेषण सीमा को VPN ऑपरेटर पर केंद्रित करता है, दूसरा उसे Tor के प्रवेश और निकास पर केंद्रित करता है। दोनों ऐप्लिकेशन एक साथ खुले रखने पर जो मिलता है, वह इनमें से कोई नहीं है।

कुछ भी कॉन्फ़िगर करने से पहले लिखें कि काम को कौन-सा क्रम चाहिए, क्योंकि दोनों को अलग सॉफ़्टवेयर सेटिंग्स चाहिए और दोनों अलग जगहों पर विफल होते हैं। गलत नाम वाला क्रम आपको एक घंटे तक गलत परत में खराबी खोजने भेजता है। नीचे सब कुछ Tor पहले मानता है।

बाकी सब से पहले ट्रांसपोर्ट जाँचें

Tor का SOCKS इंटरफ़ेस TCP धाराएँ ढोता है और सामान्य UDP संबंध नहीं देता। जिस VPN का ट्रांसपोर्ट UDP है, वह उस प्रॉक्सी को सामान्य नेटवर्क इंटरफ़ेस की तरह नहीं ले सकता, और कोई क्लाइंट सेटिंग यह नहीं बदलती कि प्रॉक्सी क्या आगे भेजने को तैयार है। सामान्य रूप में WireGuard स्पष्ट रूप से शिकार है। TCP मोड में OpenVPN प्रोफ़ाइल सामान्य उपाय है, और उसे भी स्पष्ट रूप से प्रॉक्सी इस्तेमाल करने को कहना पड़ता है।

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

उसके ज़रिए सुरंग की खराबी खोजने से पहले पुष्टि करें कि प्रॉक्सी सुन रही है और एक साधारण HTTPS अनुरोध ढो सकती है। अगर साधारण अनुरोध विफल हो, तो VPN क्लाइंट कभी सफल नहीं होगा और उसके लॉग आपको कारण नहीं बताएँगे।

पर्यवेक्षक का नक्शा फिर से लिखें

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

वह हर गंतव्य तक वितरित रास्ता भी फिर से नहीं बनाता। Tor Browser हर साइट के लिए नया सर्किट बनाता है; Tor पर ढोया गया VPN एक सुरंग बनाता है, और उसके पीछे की हर साइट वही एंडपॉइंट साझा करती है। अंतर को हटाने वाली सीमा नहीं, डिज़ाइन तथ्य मानें।

टूटने पर विफलता की परतें गिनें

टूटी सेटिंग में कम से कम चार स्वतंत्र परतें होती हैं: SOCKS कनेक्शन, VPN सर्वर के साथ TLS हैंडशेक, स्वयं VPN हैंडशेक, और फिर सुरंग के भीतर रूटिंग या नाम-समाधान। हर एक अलग लक्षण से विफल होती है और हर एक को अलग मरम्मत चाहिए। सुरंग न उठने पर प्रमाणपत्र जाँच ढीली करना क्लासिक गलत निदान है, और यह ट्रांसपोर्ट समस्या को सुरक्षा समस्या बना देता है।

पहली विफल परत दर्ज करें और वहीं रुकें। प्रॉक्सी का इनकार और अस्वीकृत कुंजी एक ही घटना के रूपांतर नहीं हैं।

अगर ख़तरे का मॉडल Tor Browser के बचाव चाहता है तो रुकें

Tor द्वारा ढोए गए VPN से मनमाने ऐप्लिकेशन रूट करने पर उन ऐप्लिकेशन को Tor Browser की फ़िंगरप्रिंट और अलगाव सुविधाएँ नहीं मिलतीं। उनके खाते, पहचानकर्ता और अपना नेटवर्क व्यवहार प्रासंगिक रहते हैं, और सुरंग उनमें से किसी को सामान्य नहीं बनाती। अगर लक्ष्य दूसरे उपयोगकर्ताओं के साथ घुलने वाला ब्राउज़र है, तो यह क्रम वह नहीं देता।

Tor Project स्वयं ऐसे संयोजनों से चेताता है जिन्हें उपयोगकर्ता ठीक से कॉन्फ़िगर नहीं कर सकते, और यह अधिकांश लोगों पर लागू होता है। यह संकीर्ण ख़तरा मॉडल के लिए जानबूझकर किया गया डिज़ाइन है, पूरे डिवाइस के अनाम ट्रैफ़िक का शॉर्टकट नहीं।