VPN से पहले Tor तैयार: स्टार्टअप गेट का सही क्रम

tor प्रक्रिया की निगरानी करके फिर VPN शुरू करना इस स्टैक को गलत तरीके से बनाने का सबसे आम रास्ता है। डेमॉन क्लाइंट स्ट्रीम ले जाने से बहुत पहले दिखाई देता है, और तय देरी एक अनुमान है जिसे निर्भरता का रूप दिया गया है। गेट वही स्थिति होनी चाहिए जिसकी अगले घटक को वास्तव में आवश्यकता है। नीचे दिए चार चरणों को क्रम से पूरा करें और हर एक को अलग शर्त मानें, न कि समायोजित करने योग्य देरी।

चरण 1: वह ट्रांसपोर्ट चुनें जो आपके पास वास्तव में है

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

फिर पुष्टि करें कि आपका क्लाइंट किसी SOCKS प्रॉक्सी तक पहुँच ही सकता है। OpenVPN 2.6 TCP प्रोफ़ाइल के लिए socks-proxy विकल्प का दस्तावेज़ीकरण करता है, और अलग-अलग क्लाइंट अलग प्रॉक्सी समर्थन देते हैं। जो लॉन्चर प्रॉक्सी विकल्प को चुपचाप अनदेखा करता है वह सीधे जुड़ जाएगा और काम करता दिखेगा, जो विफल होने से भी बुरा है।

चुने गए ट्रांसपोर्ट को रनबुक में लिखें, क्योंकि हर बाद की जाँच इसी पर निर्भर है।

चरण 2: bootstrap चरण पढ़ें, प्रक्रिया सूची नहीं

Tor का नियंत्रण प्रोटोकॉल GETINFO status/bootstrap-phase का उत्तर नवीनतम bootstrap स्थिति से देता है, जिसमें प्रगति प्रतिशत और सारांश टैग शामिल होते हैं। वह उत्तर इसलिए उपयोगी है क्योंकि नियंत्रक डेमॉन के bootstrap पूरा करने के बाद भी जुड़ सकता है। जो सुपरवाइज़र केवल घटनाएँ सुनता है वह उस स्थिति को चूक जाएगा जहाँ सुपरवाइज़र शुरू होने से पहले ही Tor तैयार था।

नियंत्रण कनेक्शन को ठीक से प्रमाणित करें। नियंत्रण पोर्ट एक प्रशासनिक इंटरफ़ेस है, और जो कोई इससे बात कर सकता है वह डेमॉन को पुनः कॉन्फ़िगर कर सकता है। इसे localhost पर रखें, कुकी या पासवर्ड प्रमाणीकरण सक्षम रखें, और स्टार्टअप स्क्रिप्ट आसान बनाने के लिए इनमें से किसी को न हटाएँ।

शुरुआत में चरण एक बार पढ़ें, फिर लाइव दृश्य के लिए प्रगति घटनाओं की सदस्यता लें।

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

प्रगति 100 और done टैग वाला उत्तर इसका अर्थ है कि डेमॉन ने अपना स्टार्टअप पूरा कर लिया। इसका अर्थ यह अभी नहीं है कि आपके गंतव्य तक कोई उपयोगी सर्किट मौजूद है।

चरण 3: क्लाइंट सर्किट घटना की प्रतीक्षा करें

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

घटना को प्रयास की अनुमति मानें, किसी विशिष्ट गंतव्य के बारे में गारंटी नहीं। निकास नीति अभी भी दूरस्थ पीयर को अस्वीकार कर सकती है, और VPN का अपना हैंडशेक भी अभी भी ऐसे कारणों से विफल हो सकता है जिनका Tor से कोई संबंध नहीं है।

कोड में दोनों शर्तें अलग रखें। ready नाम का एक बूलियन उन्हें मिला देगा और अगली घटना को अपठनीय बना देगा।

चरण 4: VPN को उसके अपने हैंडशेक पर गेट करें

VPN की अपनी तैयारी शर्त है, और केवल वही साबित करती है कि सुरंग ऊपर आई। प्रतीक्षा करें कि क्लाइंट आवंटित पते के साथ जुड़ी स्थिति की रिपोर्ट करे, फिर जाँचें कि प्रॉक्सी की आवश्यकता लागू रही। जो पुनः प्रयास लूप एक विफलता के बाद socks-proxy विकल्प छोड़ देता है वह सीधे जुड़ जाएगा और पूरे डिज़ाइन को चुपचाप हरा देगा।

पीयर के अप्राप्य होने पर क्या होगा, यह जानने की आवश्यकता पड़ने से पहले तय करें। दृश्य विफलता के साथ सीमित पुनः प्रयास अनंत लूप की तुलना में संचालित करना आसान है, और यह निगरानी प्रणाली को सतर्क करने के लिए कुछ देता है। यही निर्णय कैरियर पर भी लागू होता है: यदि Tor पुनः शुरू होता है, तो VPN को तोड़कर फिर से गेट करना होगा, मृत सर्किट पर चलने नहीं देना चाहिए।

अंत में, VPN के बंद रहने के दौरान अनुप्रयोग की अपनी नीति लागू रखें। सही ढंग से प्रतीक्षा करने वाला सुपरवाइज़र असंबंधित प्रक्रिया को सीधे ट्रैफ़िक भेजने से रोकने के लिए कुछ नहीं करता।

उन चार संक्रमणों की जाँच करें जिन्हें आपको पार करना है

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

उन्हें जानबूझकर, एक बार में एक चलाएँ, और प्रक्रिया सूची के बजाय स्थिति परिवर्तन पढ़ें।

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

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