VPN, Tor आणि अनुप्रयोगाचा प्रॉक्सी एकमेकांवर ठेवणे गोपनीयता वाढवल्यासारखे वाटते, पण प्रत्यक्षात जिथे जोडणी मरू शकते अशा ठिकाणांची संख्या वाढवते। तिन्ही साधने स्वतःला निरोगी सांगत असताना ब्राउझर फिरत राहणे हा नेहमीचा परिणाम। तिन्ही सेटिंग्ज एकाच वेळी बदलल्यास कोण खोटे बोलत आहे याचा एकमेव सुगावाही नाहीशा होतो।

आधी इच्छित मार्ग क्रमाने काढा, कोणता प्रोग्राम कोणती जोडणी उघडतो आणि प्रत्येक टप्प्यावर कोणते नाव सोडवले जाते ते लिहा।

थर एकत्र येत नाहीत, ते एकमेकांवर परिणाम करतात

Tor आधी VPN असणे म्हणजे Tor क्लायंटची प्रवेश जोडणी बोगद्याच्या आतून जाते। Tor मधून वाहून नेलेला VPN म्हणजे VPN क्लायंटचा स्वतःचा शेवटचा बिंदू Tor मधून पोहोचण्यायोग्य असावा लागतो, ही पूर्णपणे वेगळी अट आहे। ब्राउझरचा प्रॉक्सी ऑपरेटिंग सिस्टमला माहीत नसलेली आणखी एक उडी जोडतो। तीन मांडण्या, तीन स्वतंत्र अवलंबन याद्या।

प्रत्येक मांडणी बदलते की काय सोडवता येईल, काय वाहून नेता येईल आणि पहिले पॅकेट कोण पाहील। त्यातील फक्त एकच तुमचे इच्छित संरचना असू शकते।

सरळ मार्गही आकृतीत जोडा। फॉलबॅक मार्ग, विभाजित बोगद्याचा अपवाद किंवा प्रॉक्सी बायपास पान लोड करू शकतात, पण तुम्हाला तपासायची असलेली साखळी गुपचूप वगळतात, आणि अशी यश अपयशापेक्षा जास्त भ्रमित करते।

क्रम ठरवतो की काय वाहून नेता येईल

Tor त्याच्या SOCKS इंटरफेसवरून TCP प्रवाह वाहून नेतो, आणि प्रॉक्सीला होस्टनाव सोडवायला सांगणारा क्लायंट शोध सर्किटच्या आत ठेवतो। सामान्य संरचनांमध्ये UDP अशा प्रकारे जात नाही, म्हणून मध्यभागी अतिरिक्त TCP रिले न घालता WireGuard बोगदा Tor मध्ये नेस्ट करता येत नाही।

OpenVPN ला TCP वर जबरदस्ती करता येते, त्यामुळे ही मांडणी किमान वर्णन करण्यायोग्य आहे। ती हळू आणि अधिक नाजूकही आहे, आणि तुटल्यावरचा अपयशाचा देखावा बंदिस्त पोर्टसारखाच दिसतो। या दोन्हींत फरक करण्यात कोणतेही एक दुरुस्त करण्यापेक्षा जास्त वेळ जाईल अशी अपेक्षा ठेवा।

सोडवणे हा दुसरा अर्धा भाग आहे। --socks5-hostname वापरल्यास प्रॉक्सी गंतव्य सोडवतो, तर साधा --socks5 आधी स्थानिक रिझॉल्व्हरला विचारतो आणि नाव सर्किटबाहेर गळतो। हाच एक फ्लॅग ठरवतो की नावाचा शोध साखळीचा भाग आहे की तुमच्या इंटरनेट पुरवठादाराचा।

OrderWhat must resolve the endpointWhat usually breaks
VPN, then TorThe tunnel's resolverEntry guards blocked by the VPN provider's filters
Tor, then VPNThe SOCKS proxy, remotelyUDP transports, which Tor does not carry
App proxy on topThe application itselfProxy bypass rules and cached connections

पहिली तुटलेली सीमा शोधणे

पॅकेट ज्या क्रमाने जातात त्याच क्रमाने टप्पे तपासा, निरुपद्रवी विनंत्या वापरून, आणि पहिल्या अपयशी टप्प्यावर थांबा। कोणती कमांड आधी चालली ते नोंदवा, कारण क्रम हाच पुराव्याचा भाग आहे। दोन कमांड मृत सर्किट आणि मृत एग्रेस वेगळे करतात:

curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip
curl -4 -s https://api.ipify.org; echo

पहिली सांगते की विनंती SOCKS प्रॉक्सीतून अजिबात पूर्ण होते का, आणि दुसरी दाखवते की नेटवर्क सध्या कोणता पत्ता मांडत आहे। पहिली अपयशी झाली आणि दुसरी यशस्वी झाली, तर समस्या Tor क्लायंटकडे किंवा त्याआधी आहे। दोन्ही यशस्वी झाल्या आणि ब्राउझर अजूनही अपयशी झाला, तर अनुप्रयोग शेलपेक्षा वेगळा मार्ग वापरत आहे।

सार्वजनिक IP चे पानही फक्त शेवटचा दिसणारा एग्रेस वर्णन करते। त्याआधी किती उड्या होत्या ते ते सांगू शकत नाही, म्हणून एका अंकाला आकृती मानण्याऐवजी प्रत्येक साधनाच्या समर्थित स्थिती आउटपुटशी जोडून पाहा।

थर जोडणे कधी थांबवावे

एखादा थर काय भर घालतो हे एका वाक्यात सांगता येत नसेल, तर तो काढून टाका। ज्याचा उद्देश अस्पष्ट आहे अशी साखळी रात्री तीन वाजता कोणीही डीबग करू शकत नाही, आणि न स्पष्ट केलेल्या उडीचा गोपनीयता-लाभ सहसा तुम्ही गमावलेल्या उपलब्धतेपेक्षा कमी असतो।

थर खरोखर आपले स्थान कमावत असेल, तर आधी तो एकटाच तपासा, मग पुढचा जोडा आणि त्याच दोन कमांडनी मार्ग पुन्हा पुष्टी करा। नेहमीच्या वापरापूर्वी पूर्ण साखळी पुनर्संचयित करा, आणि TLS पडताळणी व प्रमाणीकरण सुरू ठेवा; पान लोड व्हावे म्हणून स्वीकारलेला प्रमाणपत्र इशारा हा राउटिंगचा चकवा आहे, दुरुस्ती नाही। ठरलेला क्रम ताजा असतानाच लिहून ठेवा।

तो क्रम लिहा, प्रत्येक टप्प्यावर उत्तर देणारा रिझॉल्व्हरही धरून। तुम्ही वर्णन करू शकता अशी कार्यरत साखळी पुढचे अद्यतन टिकून राहते, तर प्रयोग करून जोडलेली कार्यरत साखळी त्याच्याबरोबर नाहीशी होते। तारीख आणि आवृत्त्या जोडा, म्हणजे नंतरचे अपयश स्मरणातून वाद घालण्याऐवजी ज्ञात चांगल्या स्थितीशी तुलना करता येईल। मजकूर फाइलमधील दहा ओळी एका संध्याकाळचा अंदाज वाचवतात।

संबंधित लेख