eddieivan01/ioxOutil pour le redirection de ports et proxy intranet
Anglais | 中文
Outil pour le transfert de ports et le proxy intranet, comme lcx/ew, mais en mieux
lcx et ew sont géniaux, mais peuvent être améliorés.
Quand je les ai utilisés pour la première fois, je n’arrivais pas à retenir ces paramètres compliqués pendant longtemps, comme tran, slave, rcsocks, sssocks.... Le mode de fonctionnement est clair, pourquoi concevoir des paramètres comme ça (surtout ceux d’ew : -l -d -e -f -g -h) ?
De plus, je pense que la logique de programmation réseau pourrait être optimisée.
Par exemple, avec la commande lcx -listen 8888 9999, le client doit d’abord se connecter à :8888, puis à :9999 ; avec iox, il n’y a pas d’ordre imposé pour les deux ports. Et avec la commande lcx -slave 1.1.1.1 8888 1.1.1.1 9999, lcx connecte deux hôtes en série, alors qu’il serait plus efficace de le faire en parallèle, comme le fait iox.
De plus, iox propose une fonction de chiffrement du trafic (utile en présence d’un IDS sur la cible). En fait, vous pouvez utiliser iox comme un simple ShadowSocks.
Et iox prend également en charge le transfert de trafic UDP.
Bien sûr, comme iox est écrit en Go, le programme lié statiquement est un peu volumineux : 2,2 Mo (800 Ko après compression UPX).
Comme vous pouvez le voir, tous les paramètres sont uniformes. -l/--local signifie écouter sur un port local ; -r/--remote signifie se connecter à un hôte distant.
Remarque : à partir de v0.4, -l/--local permet de spécifier l’adresse IP d’écoute. Si seul le port est spécifié, la valeur par défaut est 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` est aussi possible, mais déconseillé, car `-l *:9999` (écoute sur 0.0.0.0:9999 avec chiffrement) est ambigu.
Écoute sur 0.0.0.0:8888 et 0.0.0.0:9999, transfère le trafic entre les deux connexions.
./iox fwd -l 8888 -l 9999
Écoute sur 0.0.0.0:8888, transfère le trafic vers 1.1.1.1:9999.
./iox fwd -l 8888 -r 1.1.1.1:9999
Connecte 1.1.1.1:8888 et 1.1.1.1:9999, transfère le trafic entre les deux connexions.
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999
Démarre un serveur Socks5 sur 0.0.0.0:1080.
./iox proxy -l 1080
Démarre un serveur Socks5 sur la machine contrôlée, puis le transmet vers un VPS Internet.
Le VPS fait suivre 0.0.0.0:9999 vers 0.0.0.0:1080.
Vous devez les utiliser par paire, car cela inclut un protocole simple pour contrôler la reconnexion.
./iox proxy -r 1.1.1.1:9999
./iox proxy -l 9999 -l 1080 // attention, les deux ports sont dans l’ordre
pour ew :
./ew -s rcsocks -l 1080 -e 9999
./ew -s rssocks -d 1.1.1.1 -e 9999
Connectez-vous ensuite à l’hôte intranet.
# proxychains.conf
# socks5://1.1.1.1:1080
$ proxychains rdesktop 192.168.0.100:3389
Par exemple, nous transférons le port 3389 de l’intranet vers notre VPS.
// hôte contrôlé
./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565
// notre VPS
./iox fwd -l *8888 -l 33890 -k 656565
C’est simple à comprendre : le trafic entre l’hôte contrôlé et notre VPS:8888 sera chiffré. La clé pré-partagée est 'AAA', iox l’utilisera pour générer une clé de seed et un nonce (Normalement, le nonce ne devrait pas être réutilisé. Mais comme le chiffrement d’iox ne sert qu’à contourner un IDS, pour ne pas allouer d’espace supplémentaire, le chiffrement du flux TCP réutilise le nonce), puis chiffre avec Xchacha20 (remplacement d’AES-CTR par Xchacha20 dans la version v0.3).
Donc, le * doit être utilisé en paires.
./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
Utiliser iox comme un simple ShadowSocks.
// ssserver
./iox proxy -l *9999 -k 000102
// sslocal
./iox fwd -l 1080 -r *VPS:9999 -k 000102
Il suffit d’ajouter l’option -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
ATTENTION : Lorsque vous créez une connexion multi-étapes, le mode Remote2Remote-UDP-mode doit être lancé en dernier, c’est la commande n°3 dans l’exemple ci-dessus.
Le transfert UDP peut avoir un comportement différent de celui attendu. En réalité, sur GitHub, il n’y a actuellement que des exemples de transfert d’un écouteur local vers un hôte distant, donc je n’ai pu l’implémenter que selon ma compréhension.
Vous pouvez en trouver la raison dans le code source. Si vous avez des idées, les PR / issues sont les bienvenus.
The MIT license