Tor रिले बनाम VPN सर्वर: ये एक-दूसरे के विकल्प क्यों नहीं हैं

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

जाँचें कि पोर्ट वास्तव में क्या सेवा देता है

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

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

प्रमाणपत्र के होने की बात नहीं, प्रमाणपत्र को पढ़ें। रिले जान-बूझकर साधारण नाम वाला स्व-हस्ताक्षरित प्रमाणपत्र प्रस्तुत करते हैं, क्योंकि रिले का ट्रैफ़िक साधारण HTTPS जैसा दिखना चाहिए; VPN सर्वर का प्रमाणपत्र वह नाम लिए होता है जिसकी आपकी प्रोफ़ाइल अपेक्षा करती है। अगर सामने वाला पक्ष VPN प्रोटोकॉल के पहले पैकेट का कभी जवाब नहीं देता, तो प्रोफ़ाइल में कोई भी संपादन नतीजा नहीं बदलेगा।

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

रिले की भूमिका जाँचें, नेटवर्क का आकार नहीं

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

एग्ज़िट नीति पढ़ने लायक है क्योंकि यही एकमात्र हिस्सा है जो फ़ॉरवर्डिंग नियम जैसा लगता है, और यह उन गंतव्यों को नियंत्रित करती है जहाँ एग्ज़िट बाहर जाने देगा, न कि उन क्लाइंट को जिन्हें अंदर आने दिया जाता है। पोर्ट 25 रोकने वाली सख़्त एग्ज़िट नीति बाहर जाने वाले दुरुपयोग के नियंत्रण के बारे में कुछ कहती है, इस बारे में नहीं कि आप OpenVPN क्लाइंट को मशीन की ओर इंगित कर सकते हैं या नहीं।

अगर आप प्रतिष्ठा से तर्क कर रहे हैं तो रुकें: चूँकि रिले ट्रैफ़िक आगे भेजते हैं, पते को आपका ट्रैफ़िक स्वीकार करना चाहिए। Tor रास्ते सर्वसम्मति और अपने प्रोटोकॉल से चुनता है; VPN क्लाइंट भागीदार नहीं है और उसके पास जुड़ने के लिए कोई सर्किट नहीं है।

जाँचें कि SOCKS श्रोता स्थानीय है या सार्वजनिक

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

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

बाइंड पता ही संकेत है। 127.0.0.1:9050 पर SocksPort अपना काम कर रहा है; जो 0.0.0.0 पर सुनता है और बाहर से पहुँच में है, वह खुला प्रॉक्सी है, और Tor के अपने एक्सेस नीति नियंत्रण ठीक इसलिए मौजूद हैं कि यह जोखिम समस्या है, विशेषता नहीं।

जिस अनुप्रयोग को Tor चाहिए, उसे लूपबैक पोर्ट की ओर इंगित करें और Tor को नाम हल करने दें, जो ऊपर वाला socks5h रूप करता है। उस पोर्ट के लिए रिले का पता न रखें; रिले वह इंटरफ़ेस नहीं देता जो आपका अनुप्रयोग माँगता है।

जाँचें कि VPN प्रोफ़ाइल किसी असली एंडपॉइंट से मेल खाती है

VPN प्रोफ़ाइल अपेक्षाओं का एक बंडल है: OpenVPN को सर्वर प्रमाणपत्र या CA, क्लाइंट प्रमाणपत्र और कुंजी, और आमतौर पर TLS कुंजी चाहिए, जबकि WireGuard को पीयर की सार्वजनिक कुंजी, एक एंडपॉइंट और अनुमत IP चाहिए। इनमें से कोई भी पते और खुले पोर्ट से निकाला नहीं जा सकता, इसलिए इस तरह बनी प्रोफ़ाइल जुड़ने के बजाय पहले आदान-प्रदान में विफल होती है।

जब आपको कोई प्रोफ़ाइल सौंपी जाए, तो उसे किसी ऐसे एंडपॉइंट के सामने जाँचें जिसे आप नियंत्रित करते हैं या ऐसे प्रदाता के सामने जिसे आप पहचान सकते हैं:

wg show
openvpn --config client.ovpn --verb 4

OpenVPN लॉग में TLS बातचीत की त्रुटि बेमेल को सीधे नाम देती है; wg show में, हैंडशेक पंक्ति के बिना कोई पीयर कभी एक भी पूरा नहीं कर पाया है। दोनों क्लाइंट के घूमते संकेतक से ज़्यादा जानकारी देते हैं, और दोनों Tor की ओर नहीं, कुंजी सामग्री या प्रोटोकॉल की ओर इशारा करते हैं।

जाँचें कि आपको असल में कौन-सी सुरक्षा चाहिए

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

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

कुछ भी आयात करने से पहले, चारों बातें पक्की करें:

• पोर्ट आपके प्रोटोकॉल का हैंडशेक पूरा करता है, केवल TCP कनेक्शन नहीं।
• आप होस्ट की भूमिका जानते हैं और फ़ॉरवर्डिंग को अनुमति नहीं मानते।
• आप जो SOCKS श्रोता इस्तेमाल करते हैं वह लूपबैक और आपका है, किसी और के रिले पर सार्वजनिक पोर्ट नहीं।
• प्रोफ़ाइल की कुंजियाँ या प्रमाणपत्र उसी एंडपॉइंट के हैं जिससे आप जुड़ रहे हैं।