eddieivan01/ioxStrumento per il port forwarding e proxy di intranet
Inglese | 中文
Strumento per port forwarding e proxy di rete interna, simile a lcx/ew, ma migliore
lcx e ew sono fantastici, ma possono essere migliorati.
Quando li ho usati per la prima volta, non riuscivo a ricordare a lungo questi parametri complicati, come tran, slave, rcsocks, sssocks.... La modalità di lavoro è chiara, perché progettare parametri in questo modo (soprattutto -l -d -e -f -g -h di ew)?
Inoltre, penso che la logica di programmazione di rete possa essere ottimizzata.
Ad esempio, mentre si esegue il comando lcx -listen 8888 9999, il client deve connettersi prima a :8888, poi a :9999; in iox non c'è un ordine obbligatorio per le due porte. E mentre si esegue il comando lcx -slave 1.1.1.1 8888 1.1.1.1 9999, lcx si connette alle due macchine in serie, ma è più efficiente connettersi in parallelo, come fa iox.
Inoltre, iox fornisce la funzionalità di crittografia del traffico (utile quando è presente un IDS sul target). In pratica, puoi usare iox come un semplice ShadowSocks.
E iox supporta anche il forwarding del traffico UDP.
Ovviamente, poiché iox è scritto in Go, il programma statico-link è un po' grande: 2.2 MB (800 KB dopo compressione UPX).
Come puoi vedere, tutti i parametri sono uniformi. -l/--local significa ascoltare su una porta locale; -r/--remote significa connettersi a un host remoto
Nota: dopo la v0.4, -l/--local può specificare su quale IP ascoltare. Se vengono specificate solo le porte, il default è 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` è anche accettabile, ma non raccomandato. Perché `-l *:9999` (ascolta su 0.0.0.0:9999 con crittografia) è ambiguo
Ascolta su 0.0.0.0:8888 e 0.0.0.0:9999, inoltra il traffico tra le due connessioni
./iox fwd -l 8888 -l 9999
Ascolta su 0.0.0.0:8888, inoltra il traffico a 1.1.1.1:9999
./iox fwd -l 8888 -r 1.1.1.1:9999
Connette 1.1.1.1:8888 e 1.1.1.1:9999, inoltra tra le due connessioni
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999
Avvia un server Socks5 su 0.0.0.0:1080
./iox proxy -l 1080
Avvia un server Socks5 sulla macchina controllata, quindi inoltra al VPS su internet
VPS inoltra 0.0.0.0:9999 a 0.0.0.0:1080
Devi usarli in coppia, perché contiene un semplice protocollo per controllare la connessione di ritorno
./iox proxy -r 1.1.1.1:9999
./iox proxy -l 9999 -l 1080 // nota, le due porte sono in ordine
per ew:
./ew -s rcsocks -l 1080 -e 9999
./ew -s rssocks -d 1.1.1.1 -e 9999
Poi connetti la macchina della rete interna
# proxychains.conf
# socks5://1.1.1.1:1080
$ proxychains rdesktop 192.168.0.100:3389
Ad esempio, inoltriamo la porta 3389 della rete interna al nostro VPS
// macchina controllata
./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565
// nostro VPS
./iox fwd -l *8888 -l 33890 -k 656565
È facile da capire: il traffico tra la macchina controllata e il nostro VPS:8888 verrà crittografato, la chiave pre-condivisa è 'AAA', iox la userà per generare una chiave seed e un nonce (Normalmente, il nonce non dovrebbe essere riutilizzato. Ma considerando che la crittografia di iox è solo per bypassare IDS, per non allocare spazio extra, la crittografia del flusso TCP riutilizzerà il nonce), poi crittografa con Xchacha20 (sostituisce AES-CTR con Xchacha20 nella versione v0.3)
Quindi, * deve essere usato in coppia
./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
Usare iox come un semplice ShadowSocks
// ssserver
./iox proxy -l *9999 -k 000102
// sslocal
./iox fwd -l 1080 -r *VPS:9999 -k 000102
Basta aggiungere l'opzione 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
ATTENZIONE: Quando crei una connessione multi-stadio, la modalità Remote2Remote-UDP-mode deve essere avviata per ultima, che è il comando n.3 nell'esempio sopra
Il forwarding UDP potrebbe avere un comportamento diverso da quanto ti aspetti. In realtà, su GitHub al momento ci sono solo esempi di forwarding da un listener locale a un host remoto, quindi posso implementarli solo secondo la mia comprensione.
Puoi trovare il motivo nel codice sorgente. Se hai idee, PR / issue sono benvenuti.
The MIT license