eddieivan01/ioxHerramienta para reenvío de puertos y proxy de intranet
Inglés | 中文
Herramienta para reenvío de puertos y proxy de intranet, al igual que lcx/ew, pero mejor
lcx y ew son geniales, pero se pueden mejorar.
Cuando los usé por primera vez, no podía recordar durante mucho tiempo estos parámetros complicados, como tran, slave, rcsocks, sssocks.... El modo de trabajo es claro, ¿por qué diseñan parámetros así (especialmente los -l -d -e -f -g -h de ew)?
Además, creo que la lógica de programación de red podría optimizarse.
Por ejemplo, al ejecutar el comando lcx -listen 8888 9999, el cliente debe conectarse primero a :8888 y luego a :9999; en iox no hay límite en el orden de los dos puertos. Y al ejecutar el comando lcx -slave 1.1.1.1 8888 1.1.1.1 9999, lcx conecta dos hosts en serie, pero es más eficiente conectarlos de forma concurrente, como hace iox.
Además, iox proporciona una función de cifrado de tráfico (útil cuando hay un IDS en el objetivo). De hecho, puedes usar iox como un ShadowSocks simple.
Y iox también proporciona reenvío de tráfico UDP.
Por supuesto, debido a que iox está escrito en Go, el programa enlazado estáticamente es un poco grande; el programa sin comprimir es de 2.2 MB (800 KB después de la compresión UPX).
Puedes ver que todos los parámetros son uniformes. -l/--local significa escuchar en un puerto local; -r/--remote significa conectarse a un host remoto
Nota: a partir de v0.4, -l/--local puede especificar en qué IP escuchar. Si solo se especifican puertos, el valor predeterminado es 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
Escuchar en 0.0.0.0:8888 y 0.0.0.0:9999, reenviar tráfico entre 2 conexiones
./iox fwd -l 8888 -l 9999
Escuchar en 0.0.0.0:8888, reenviar tráfico a 1.1.1.1:9999
./iox fwd -l 8888 -r 1.1.1.1:9999
Conectar 1.1.1.1:8888 y 1.1.1.1:9999, reenviar entre 2 conexiones
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999
Iniciar servidor Socks5 en 0.0.0.0:1080
./iox proxy -l 1080
Iniciar servidor Socks5 en el host controlado, luego reenviar a VPS de internet
VPS reenvía 0.0.0.0:9999 a 0.0.0.0:1080
Debes usarlos en pareja, porque contiene un protocolo simple para controlar la conexión de retorno.
./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
Luego conectarse al host de la intranet
# proxychains.conf
# socks5://1.1.1.1:1080
$ proxychains rdesktop 192.168.0.100:3389
Por ejemplo, reenviamos el puerto 3389 de la intranet a nuestro 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
Es fácil de entender: el tráfico entre el host controlado y nuestro VPS:8888 será cifrado, la clave secreta precompartida es 'AAA', iox la usará para generar la clave semilla y el nonce (Normalmente, el nonce no debería reutilizarse. Pero considerando que el cifrado de iox es solo para evadir IDS, para no asignar espacio extra, el cifrado de flujo TCP reutilizará el nonce) y luego cifrar con Xchacha20 (reemplazó AES-CTR con Xchacha20 en la versión v0.3).
Por lo tanto, el * debe usarse en pares
./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
Usando iox como un ShadowSocks simple
// ssserver
./iox proxy -l *9999 -k 000102
// sslocal
./iox fwd -l 1080 -r *VPS:9999 -k 000102
Solo necesita añadir la opción de 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
AVISO: Cuando realices una conexión multietapa, el Remote2Remote-UDP-mode debe iniciarse al final, que es el comando No.3 en el ejemplo anterior
El reenvío UDP puede tener un comportamiento no esperado. De hecho, en GitHub ahora solo hay ejemplos de reenvío de un listener local a un host remoto, así que solo puedo implementarlos según mi entendimiento.
Puedes encontrar el por qué en el código fuente. Si tienes alguna idea, PR / issue son bienvenidos.
Licencia MIT