eddieivan01/ioxFerramenta para redirecionamento de portas e proxy de intranet
Inglês | Chinês
Ferramenta para encaminhamento de portas e proxy de intranet, como lcx/ew, mas melhor
lcx e ew são ótimos, mas podem ser melhorados.
Quando os usei pela primeira vez, não conseguia lembrar por muito tempo desses parâmetros complicados, como tran, slave, rcsocks, sssocks.... O modo de funcionamento é claro, por que eles projetam parâmetros assim (especialmente -l -d -e -f -g -h do ew)?
Além disso, acho que a lógica de programação de rede poderia ser otimizada.
Por exemplo, ao executar o comando lcx -listen 8888 9999, o cliente deve conectar primeiro a :8888, depois a :9999. No iox, não há limite quanto à ordem das duas portas. E ao executar o comando lcx -slave 1.1.1.1 8888 1.1.1.1 9999, o lcx conecta dois hosts sequencialmente, mas é mais eficiente conectar em concorrência, como o iox faz.
Além disso, o iox fornece uma funcionalidade de criptografia de tráfego (útil quando há um IDS no alvo). Na verdade, você pode usar o iox como um simples ShadowSocks.
E o iox também oferece encaminhamento de tráfego UDP.
Claro, como o iox é escrito em Go, o programa linkado estaticamente é um pouco grande: o programa bruto tem 2,2 MB (800 KB após compressão UPX).
Você pode ver que todos os parâmetros são uniformes. -l/--local significa escutar em uma porta local; -r/--remote significa conectar ao host remoto.
Nota: após v0.4, -l/--local pode especificar em qual IP escutar. Se apenas portas forem especificadas, o padrão é 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` também funciona, mas não é recomendado. Pois `-l *:9999` (escutar em 0.0.0.0:9999 com criptografia) é ambíguo.
Escuta em 0.0.0.0:8888 e 0.0.0.0:9999, encaminha tráfego entre 2 conexões
./iox fwd -l 8888 -l 9999
Escuta em 0.0.0.0:8888, encaminha tráfego para 1.1.1.1:9999
./iox fwd -l 8888 -r 1.1.1.1:9999
Conecta 1.1.1.1:8888 e 1.1.1.1:9999, encaminha entre 2 conexões
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999
Inicia servidor Socks5 em 0.0.0.0:1080
./iox proxy -l 1080
Inicia servidor Socks5 no host controlado e encaminha para VPS da internet
VPS encaminha 0.0.0.0:9999 para 0.0.0.0:1080
Você deve usar em par, pois contém um protocolo simples para controlar a conexão de retorno
./iox proxy -r 1.1.1.1:9999
./iox proxy -l 9999 -l 1080 // observe, as duas portas estão em ordem
para ew:
./ew -s rcsocks -l 1080 -e 9999
./ew -s rssocks -d 1.1.1.1 -e 9999
Então conecte-se ao host da intranet
# proxychains.conf
# socks5://1.1.1.1:1080
$ proxychains rdesktop 192.168.0.100:3389
Por exemplo, vamos encaminhar a porta 3389 da intranet para nossa VPS
// host controlado
./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565
// nossa VPS
./iox fwd -l *8888 -l 33890 -k 656565
É fácil de entender: o tráfego entre o host controlado e nossa VPS:8888 será criptografado, a chave secreta pré-compartilhada é 'AAA', o iox a usará para gerar a chave semente e nonce (Normalmente, nonce não deve ser reutilizado. Mas considerando que a criptografia do iox é apenas para bypass de IDS, para não alocar espaço extra, a criptografia do fluxo TCP reutilizará o nonce), então criptografa com Xchacha20 (substituiu AES-CTR por Xchacha20 na versão v0.3)
Portanto, o * deve ser usado em 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 um simples ShadowSocks
// ssserver
./iox proxy -l *9999 -k 000102
// sslocal
./iox fwd -l 1080 -r *VPS:9999 -k 000102
Basta adicionar a opção 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: Quando você faz uma conexão em vários estágios, o Remote2Remote-UDP-mode deve ser iniciado por último, que é o comando nº 3 no exemplo acima
O encaminhamento UDP pode ter um comportamento diferente do esperado. Na verdade, atualmente no GitHub, existem apenas exemplos de encaminhamento de um listener local para um host remoto, então só pude implementá-los com meu entendimento.
Você pode descobrir o motivo no código-fonte. Se tiver ideias, PR / issues são bem-vindos.
A licença MIT