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 सामान्यतया बढी उपयुक्त हुन्छ: यसले एपलाई प्रोक्सी प्रोटोकल बोल्न भन्नुबिना त्यसका प्याकेट बोक्छ, तर पूर्ण रूपमा फरक अनामताका गुणहरूको मूल्यमा। प्रत्येक उपकरणलाई यसले कागजात गरेको कामका लागि प्रयोग गर्नुहोस्, र तिनीहरूबीचको कुनै पनि पुललाई आफ्नै समीक्षा चाहिने छुट्टै प्रणाली मान्नुहोस्। अन्तिम प्रतिवेदनमा कुन तहले कुन ट्रान्सपोर्ट बोक्छ लेख्नुहोस्, ताकि अर्को व्यक्तिले अर्को एपसँग त्यही सीमा फेरि नभेट्टाओस्।