eddieivan01/ioxИнструмент для проброса портов и внутрисетевого прокси
Английский | Китайский
Инструмент для перенаправления портов и проксирования в интрасети, как 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,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` is also OK, but it's not recommended. Because `-l *:9999`(listen on 0.0.0.0:9999 with encryption) is ambiguous
-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 // notice, the two port are in order
for 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.
// be-controller host
./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565
// our VPS
./iox fwd -l *8888 -l 33890 -k 656565
Это легко понять: трафик между управляемым хостом и нашим VPS:8888 будет зашифрован, предварительно согласованный секретный ключ — 'AAA', iox использует его для генерации seed-ключа и nonce (Обычно nonce не должен повторно использоваться. Но учитывая, что шифрование iox предназначено только для обхода IDS, чтобы не выделять дополнительное пространство, шифрование 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