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 इंटरफेस उघडतो, डीफॉल्टनुसार loopback वर। तो श्रोता स्थानिक सोय आहे, रिले इंटरनेटला देणारी सेवा नाही, आणि त्याला सार्वजनिक प्रॉक्सी मानणे हाच लोक अनवधानाने उघडा रिले चालवण्यापर्यंत पोहोचण्याचा मार्ग आहे:

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 आवश्यक असलेल्या अनुप्रयोगासाठी त्याला loopback पोर्टकडे वळवा आणि नावे 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 श्रोता loopback आणि तुमचा आहे, दुसऱ्याच्या रिलेवरील सार्वजनिक पोर्ट नाही।
• प्रोफाइलच्या किल्या किंवा प्रमाणपत्रे तुम्ही जोडले जात असलेल्या एंडपॉइंटची आहेत।