Tor च्या SOCKS पोर्टमधून UDP: काय पार होत नाही

ॲपला SOCKS पोर्टवर निर्देशित करणे ब्राउझरसाठी काम करते आणि गेमसाठी अयशस्वी होते, आणि कारण कॉन्फिगरेशन नाही. SOCKS5 अनेक आदेश परिभाषित करते, आणि अंमलबजावणी त्यातील काहींनाच समर्थन देण्यास मुक्त आहे; Tor चा इंटरफेस स्ट्रीम कनेक्शन आणि नाव निराकरण स्वीकारतो, अनियंत्रित डेटाग्राम फॉरवर्डिंग नाही. UDP पाठवणारा आणि प्रॉक्सी ते रिले करेल अशी अपेक्षा करणारा क्लायंट असा आदेश मागतो जो सर्व्हर अंमलात आणत नाही. खालील मार्गदर्शक ते काही मिनिटांत तपासते आणि नंतर प्रत्यक्षात काम करू शकणारा ट्रान्सपोर्ट निवडते.

ॲप प्रत्यक्षात काय पाठवते ते तपासा

प्रोटोकॉलच्या नावाने नाही, ट्रान्सपोर्ट ओळखून सुरुवात करा. व्हॉइस क्लायंट HTTPS ने साइन इन करून नंतर माध्यम UDP ने वाहू शकतो; गेम TCP ने प्रमाणीकरण करून UDP ने खेळू शकतो; फाइल हस्तांतरण नियंत्रणासाठी TCP आणि शोधासाठी UDP वापरू शकते. पहिली दोन वर्तनं लॉगिन यशस्वी होईपर्यंत आणि कॉल अजूनही अयशस्वी होईपर्यंत सारखीच दिसतात, म्हणून “कनेक्ट झाले” हा संपूर्ण ॲप काम करतो याचा पुरावा नाही. काही क्लायंट स्वतःहून UDP वरून TCP वर परत जातात, ज्यामुळे अर्धवट काम करणारे सत्र अवरोधित ट्रान्सपोर्टऐवजी अस्थिर नेटवर्कसारखे दिसते.

जो भाग अयशस्वी होतो त्यासाठी गंतव्य पोर्ट आणि ट्रान्सपोर्ट लिहून घ्या. तीच एक ओळ प्रॉक्सी अजिबात मदत करू शकते का हे ठरवते.

Tor चा SOCKS इंटरफेस काय स्वीकारेल

Tor स्ट्रीम कनेक्शनसाठी SOCKS5 CONNECT आदेश आणि नावे सोडवण्यासाठी विस्तार आदेश अंमलात आणतो, म्हणून ब्राउझर कोणत्याही बदलाशिवाय त्यातून काम करतो. UDP ASSOCIATE, जो आदेश क्लायंटला फॉरवर्डिंगसाठी डेटाग्राम प्रॉक्सीकडे सोपवू देईल, तो Tor देते त्याचा भाग नाही. विस्तारांचे दस्तऐवजीकरण प्रकल्पाच्या SOCKS विस्तार तपशील मध्ये आहे, आणि ते संक्षिप्त आहे. डेटाग्राम आदेशाची अनुपस्थिती हेतुपूर्वक आहे: अनियंत्रित UDP रिले केल्याने नेटवर्कला अशी फॉरवर्डिंग भूमिका मिळेल ज्यासाठी ते कधीच रचले गेले नाही.

हे WireGuard साठीही उत्तर आहे, जे रचनेनुसार UDP आहे आणि त्याला TCP पर्यायी मार्ग नाही. WireGuard ला SOCKS पोर्टवर निर्देशित करणारा समर्थित मार्ग नाही, आणि उलट दावा करणारे काहीही दोन साधनांपैकी कोणत्याहीचे वैशिष्ट्य नसून स्वतःच्या विश्वास आणि देखभालीच्या कथेसह आवरण आहे.

OpenVPN हा अंशतः अपवाद आहे, कारण तो TCP वर बोगदा करण्यासाठी कॉन्फिगर करता येतो आणि त्याला SOCKS प्रॉक्सी पर्याय समजतो. त्यासाठी तरीही TCP साठी कॉन्फिगर केलेला सर्व्हर आणि कार्यक्षमता तसेच बोटांच्या ठशाच्या परिणामांबद्दल जाणीवपूर्वक निर्णय आवश्यक आहे, म्हणून ही रचना-निवड आहे, सुसंगततेची दुरुस्ती नाही.

तपासणी क्रमाने चालवा

प्रथम प्रॉक्सी स्ट्रीमसाठी काम करतो याची खात्री करा, जेणेकरून नंतरचे अपयश दुर्लभ पोर्टवर ढकलले जाऊ नये. नंतर ॲपचा स्वतःचा रहदारी तपासा आणि तो प्रत्यक्षात कोणते सॉकेट उघडतो ते पहा.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

यशस्वी पहिला आदेश आणि दुसऱ्या ओळीत स्थापित स्ट्रीम दाखवतात की प्रॉक्सी मार्ग रचनेनुसार काम करत आहे. तिसरा आदेश ॲपशी संबंधित स्थानिक डेटाग्राम सॉकेट शोधतो; जर क्लायंट एक उघडतो आणि थेट दूरच्या पत्त्यावर पाठवतो, तर त्याने प्रॉक्सीला कधीच विचारले नाही आणि कोणतीही प्रॉक्सी सेटिंग ते बदलणार नाही. जर तो पहिल्याच पायरीवर अयशस्वी होतो, तर थांबा आणि ॲपची चौकशी करण्यापूर्वी प्रॉक्सी मार्ग दुरुस्त करा, कारण एकाच वेळी दोन दोष अशी अहवाल तयार करतात ज्यावर कोणीही कारवाई करू शकत नाही.

मागे वळा आणि योग्य साधन निवडा

UDP क्लायंटला SOCKS पोर्टवर निर्देशित करणारे कोणतेही प्रॉक्सी पर्यावरण चल किंवा प्रति-ॲप प्रॉक्सी सेटिंग काढून टाका; ती ठेवल्यास नंतरच्या चाचण्या अस्पष्ट होतात. प्रत मधून मागील कॉन्फिगरेशन पुनर्संचयित करा, ॲप पुन्हा सुरू करा आणि मूळ वर्तन परत आले याची खात्री करा जेणेकरून तुलना स्वच्छ राहील. न पडताळलेले रोलबॅक ही फक्त स्थिती बदलली असल्याची आशा आहे.

UDP राहणे आवश्यक असलेल्या ट्रान्सपोर्टसाठी VPN सामान्यतः अधिक योग्य आहे: तो ॲपला प्रॉक्सी प्रोटोकॉल बोलण्यास सांगण्याशिवाय त्याची पॅकेट्स वाहतो, परंतु पूर्णपणे भिन्न अनामिकता गुणधर्मांच्या किंमतीवर. प्रत्येक साधन त्याच्या दस्तऐवजीकरणातील कामासाठी वापरा आणि त्यांच्यातील कोणताही पूल स्वतःच्या पुनरावलोकनाची गरज असलेली स्वतंत्र प्रणाली माना. अंतिम अहवालात कोणता स्तर कोणता ट्रान्सपोर्ट वाहतो ते लिहा, जेणेकरून पुढील व्यक्ती दुसऱ्या ॲपसह तीच सीमा पुन्हा शोधणार नाही.