Pular para a barra de ferramentas
Hacker

Ferramenta para Port Forward & Amp; Proxy da Intranet

Utensílio para encaminhamento de porta e proxy da intranet, deste modo {como} lcx / ew, porém melhor

Por que ortografar?
lcx e ew são impressionantes, porém podem ser melhorados.
quando os usei pela primeira vez, não me lembro desses parâmetros complicados por um longo tempo, {como} tran, slave, rcsocks, sssocks …. O modo de trabalho é {claro}, por que eles projetam parâmetros {como} esse (mormente o ew’s -l -d -e -f -g -h)
Além do que, acho que a lógica de programação da rede pode ser otimizada.
Por exemplo, ao executar o comando lcx -listen 8888 9999, o cliente deve se conectar a: 8888 primeiro e depois a: 9999, em iox, não há limite para o pedido em duas portas. E enquanto executa o comando lcx -slave 1.1.1.1 8888 1.1.1.1 9999, o lcx conectará dois hosts em série, porém é mais eficiente conectar-se simultaneamente, {como} o iox.
Além do que, o iox fornece o recurso de criptografia de {tráfego}. Na verdade, você pode usar o iox {como} um simples ShadowSocks.
E iox da mesma forma fornece {tráfego} UDP para a frente.
Obviamente, {como} o iox é escrito em Go, o programa de link estático é um pouco grande, o programa bruto é de 2,2 MB (800 KB depois a compactação UPX)

Particularidade

criptografia de {tráfego} (opcional)
opção CLI humanizada
otimização lógica
Encaminhamento de {tráfego} UDP

Uso
Você pode ver, todos os parâmetros são uniformes. -l / – sítio significa escutar em uma porta sítio; -r / – remote significa conectar ao host remoto

Modo dois
fwd:
Ouça em 0.0.0.0:8888 e 0.0.0.0:9999, encaminhar {tráfego} entre 2 conexões

./iox fwd -l 8888 -l 9999

para lcx:
./lcx -listen 8888 9999
Ouça em 0.0.0.0:8888, encaminhar o {tráfego} para 1.1.1.1:9999./iox fwd -l 8888 -r 1.1.1.1:9999

para lcx:
./lcx -tran 8888 1.1.1.1 9999
Conecte 1.1.1.1:8888 e 1.1.1.1:9999, encaminhar entre 2 connection./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999

para lcx:
./lcx -slave 1.1.1.1 8888 1.1.1.1 9999
procuração
Inicie o servidor Socks5 em 0.0.0.0:1080./iox proxy -l 1080

para ew:
./ew -s ssocksd -l 1080
Inicie o servidor Socks5 no host controlado, depois encaminhe para o VPS da Internet
Encaminhamento de VPS 0.0.0.0:9999 a 0.0.0.0:1080
Você deve usar em par, pois ele contém um protocolo simples para controlar a conexão traseira./iox proxy -r 1.1.1.1:9999
./iox proxy -l 9999 -l 1080 // aviso prévio, 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
Em seguida, conecte o host da intranet # proxychains.conf
# socks5: //1.1.1.1: 1080

$ proxychains rdesktop 192.168.0.100:3389

Ativar criptografia
Por exemplo, encaminhamos a porta 3389 na intranet para o nosso VPS

// host do controlador
./iox fwd -r 192.168.0.100:3389 -r * 1.1.1.1: 8888 -k 656565

// nosso VPS
./iox fwd -l * 8888 -l 33890 -k 656565
É fácil de entender: o {tráfego} entre o host controlado e o nosso VPS: 8888 será criptografado, a chave secreta pré-compartilhada é ‘AAA’, o iox a utilizará para gerar chave de semente e nonce (normalmente, o nonce não deve ser reutilizado Porém considere que a criptografia do iox é unicamente para contornar o IDS; para não alocar espaço extra, a criptografia do fluxo TCP reutilizará o nonce) e depois criptografará com o Xchacha20 (substitua AES-CTR por Xchacha20 na versão v0.3)
Assim sendo, 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 ShadowSocks simples // ssserver
./iox proxy -l * 9999 -k 000102

// sslocal
./iox fwd -l 10808 -r * VPS: 9999 -k 000102

Encaminhamento UDP
Só é necessário aditar a opção 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 de vários estágios, o modo Remote2Remote-UDP deve ser iniciado por último, que é o comando No.3 no exemplo supra
O encaminhamento de UDP pode possuir um comportamento que não é o esperado. Na verdade, no GitHub agora, existem unicamente exemplos de encaminhamento de um ouvinte sítio para um host remoto, para que eu possa implementá-los somente com o meu entendimento
Você pode encontrar o porquê no código {fonte}. Se você tiver alguma idéia, o PR / problema será bem-vindo

Deixe uma resposta

Fechar
Fechar