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