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 ميزة تشفير حركة المرور (وهي مفيدة عندما يكون هناك نظام كشف اختراق على الهدف). في الواقع، يمكنك استخدام iox كـ ShadowSocks بسيط.
كما توفر iox أيضًا توجيه حركة مرور UDP.
بالطبع، لأن iox مكتوبة بلغة Go، فإن البرنامج الثابت الحجم كبير بعض الشيء، البرنامج الخام هو 2.2 ميجابايت (800 كيلوبايت بعد ضغط UPX).
يمكنك رؤية أن جميع المعاملات موحدة. -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
بدء خادم Socks5 على 0.0.0.0:1080
./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 ستستخدمه لتوليد مفتاح البذور و nonce (عادة، لا ينبغي إعادة استخدام nonce. لكن نظرًا لأن تشفير iox هو فقط لتجاوز أنظمة كشف الاختراق، ومن أجل عدم تخصيص مساحة إضافية، فإن تشفير تيار TCP سيعيد استخدام nonce)، ثم تشفير باستخدام Xchacha20 (تم استبدال AES-CTR بـ Xchacha20 في الإصدار v0.3).
لذا، يجب استخدام * في أزواج.
./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
فقط أضف خيار سطر الأوامر -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 مرحب بها.
ترخيص MIT