eddieivan01/ioxपोर्ट फ़ॉरवर्डिंग और इंट्रानेट प्रॉक्सी के लिए टूल
English | 中文
पोर्ट फॉरवर्ड और इंट्रानेट प्रॉक्सी के लिए टूल, बिल्कुल lcx/ew जैसा, लेकिन बेहतर
lcx और ew शानदार हैं, लेकिन उनमें सुधार किया जा सकता है।
जब मैंने पहली बार उनका उपयोग किया, तो मुझे ये जटिल पैरामीटर लंबे समय तक याद नहीं रहे, जैसे tran, slave, rcsocks, sssocks...। काम का तरीका स्पष्ट है, तो उन्होंने ऐसे पैरामीटर क्यों डिज़ाइन किए (खासकर ew के -l -d -e -f -g -h)।
इसके अलावा, मुझे लगता है कि नेट प्रोग्रामिंग लॉजिक को और बेहतर बनाया जा सकता है।
उदाहरण के लिए, lcx -listen 8888 9999 कमांड चलाते समय, क्लाइंट को पहले :8888 से कनेक्ट करना होता है, फिर :9999 से, जबकि iox में दो पोर्ट के क्रम की कोई सीमा नहीं है। और lcx -slave 1.1.1.1 8888 1.1.1.1 9999 कमांड चलाते समय, lcx दो होस्ट को क्रमिक रूप से कनेक्ट करेगा, लेकिन समवर्ती रूप से कनेक्ट करना अधिक कुशल है, जैसा कि iox करता है।
इसके अलावा, iox ट्रैफ़िक एन्क्रिप्शन सुविधा प्रदान करता है (यह उपयोगी है जब टारगेट पर IDS हो)। वास्तव में, आप iox को एक साधारण ShadowSocks के रूप में उपयोग कर सकते हैं।
और iox UDP ट्रैफ़िक फॉरवर्ड भी प्रदान करता है।
बेशक, क्योंकि iox Go में लिखा गया है, स्टैटिक-लिंक प्रोग्राम थोड़ा बड़ा है, रॉ प्रोग्राम 2.2MB है (UPX कम्प्रेशन के बाद 800KB)।
आप देख सकते हैं, सभी पैरामीटर एकसमान हैं। -l/--local का मतलब है किसी स्थानीय पोर्ट पर सुनना; -r/--remote का मतलब है रिमोट होस्ट से कनेक्ट करना
नोट: v0.4 के बाद, -l/--local यह निर्दिष्ट कर सकता है कि किस IP पर सुनना है। यदि केवल पोर्ट निर्दिष्ट किए गए हैं, तो डिफ़ॉल्ट 0.0.0.0:PORT है
-l 127.0.0.1:9999 -l *127.0.0.1:9999 # 127.0.0.1:9999
-l 9999 -l *9999 # 0.0.0.0:9999
`-l :9999` भी ठीक है, लेकिन इसकी अनुशंसा नहीं की जाती है। क्योंकि `-l *:9999` (0.0.0.0:9999 पर एन्क्रिप्शन के साथ सुनना) अस्पष्ट है
0.0.0.0:8888 और 0.0.0.0:9999 पर सुनें, दो कनेक्शनों के बीच ट्रैफ़िक फॉरवर्ड करें
./iox fwd -l 8888 -l 9999
0.0.0.0:8888 पर सुनें, ट्रैफ़िक को 1.1.1.1:9999 पर फॉरवर्ड करें
./iox fwd -l 8888 -r 1.1.1.1:9999
1.1.1.1:8888 और 1.1.1.1:9999 से कनेक्ट करें, दो कनेक्शनों के बीच फॉरवर्ड करें
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999
0.0.0.0:1080 पर Socks5 सर्वर शुरू करें
./iox proxy -l 1080
नियंत्रित होस्ट पर Socks5 सर्वर शुरू करें, फिर इंटरनेट VPS पर फॉरवर्ड करें
VPS 0.0.0.0:9999 को 0.0.0.0:1080 पर फॉरवर्ड करता है
आपको इसे जोड़ी में उपयोग करना होगा, क्योंकि इसमें कनेक्ट बैक को नियंत्रित करने के लिए एक सरल प्रोटोकॉल शामिल है
./iox proxy -r 1.1.1.1:9999
./iox proxy -l 9999 -l 1080 // ध्यान दें, दो पोर्ट क्रम में हैं
ew के लिए:
./ew -s rcsocks -l 1080 -e 9999
./ew -s rssocks -d 1.1.1.1 -e 9999
फिर इंट्रानेट होस्ट से कनेक्ट करें
# proxychains.conf
# socks5://1.1.1.1:1080
$ proxychains rdesktop 192.168.0.100:3389
उदाहरण के लिए, हम इंट्रानेट में पोर्ट 3389 को अपने VPS पर फॉरवर्ड करते हैं
// नियंत्रित होस्ट
./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565
// हमारा VPS
./iox fwd -l *8888 -l 33890 -k 656565
समझना आसान है: नियंत्रित होस्ट और हमारे VPS:8888 के बीच ट्रैफ़िक एन्क्रिप्ट किया जाएगा, प्री-शेयर्ड सीक्रेट की 'AAA' है, iox इसका उपयोग सीड की और नॉन्स जनरेट करने के लिए करेगा (सामान्यतः, नॉन्स का पुन: उपयोग नहीं किया जाना चाहिए। लेकिन यह मानते हुए कि iox का एन्क्रिप्शन केवल IDS को बायपास करने के लिए है, अतिरिक्त स्थान आवंटित न करने के लिए, TCP स्ट्रीम एन्क्रिप्शन नॉन्स का पुन: उपयोग करेगा), फिर Xchacha20 के साथ एन्क्रिप्ट करें (v0.3 संस्करण में AES-CTR को Xchacha20 से बदल दिया गया)
इसलिए, * का उपयोग जोड़ी में होना चाहिए
./iox fwd -l 1000 -r *127.0.0.1:1001 -k 000102
./iox fwd -l *1001 -r *127.0.0.1:1002 -k 000102
./iox fwd -l *1002 -r *127.0.0.1:1003 -k 000102
./iox proxy -l *1003 -k 000102
$ curl google.com -x socks5://127.0.0.1:1000
iox को एक साधारण ShadowSocks के रूप में उपयोग करना
// ssserver
./iox proxy -l *9999 -k 000102
// sslocal
./iox fwd -l 1080 -r *VPS:9999 -k 000102
केवल CLI विकल्प -u जोड़ने की आवश्यकता है
./iox fwd -l 53 -r *127.0.0.1:8888 -k 000102 -u
./iox fwd -l *8888 -l *9999 -k 000102 -u
./iox fwd -r *127.0.0.1:9999 -r 8.8.8.8:53 -k 000102 -u
ध्यान दें: जब आप मल्टीस्टेज कनेक्शन बनाते हैं, तो Remote2Remote-UDP-mode सबसे अंत में शुरू किया जाना चाहिए, जो उपरोक्त उदाहरण में कमांड नंबर 3 है
UDP फॉरवर्डिंग का व्यवहार आपकी अपेक्षा के अनुसार नहीं हो सकता है। वास्तव में, GitHub पर अब केवल स्थानीय लिसनर को रिमोट होस्ट पर फॉरवर्ड करने के उदाहरण हैं, इसलिए मैं उन्हें अपनी समझ के अनुसार ही लागू कर सकता हूं
आप स्रोत कोड में इसका कारण पा सकते हैं। यदि आपके पास कोई विचार है, तो PR / issue का स्वागत है
The MIT license