eddieivan01/ioxTool für Portweiterleitung & Intranet-Proxy
Englisch | 中文
Werkzeug für Portweiterleitung & Intranet-Proxy, ähnlich wie lcx/ew, aber besser
lcx und ew sind großartig, aber sie könnten verbessert werden.
Als ich sie zum ersten Mal benutzte, konnte ich mir diese komplizierten Parameter lange nicht merken, wie tran, slave, rcsocks, sssocks.... Der Arbeitsmodus ist klar, warum haben sie Parameter so entworfen (besonders ew's -l -d -e -f -g -h)
Außerdem denke ich, dass die Netzwerkprogrammierlogik optimiert werden könnte.
Zum Beispiel muss beim Ausführen des Befehls lcx -listen 8888 9999 der Client zuerst mit :8888 verbinden, dann mit :9999, bei iox gibt es keine Reihenfolgebeschränkung für die beiden Ports.
Und beim Ausführen des Befehls lcx -slave 1.1.1.1 8888 1.1.1.1 9999 verbindet lcx zwei Hosts seriell, aber es ist effizienter, gleichzeitig zu verbinden, wie iox es macht.
Darüber hinaus bietet iox eine Verkehrsverschlüsselungsfunktion (nützlich, wenn ein IDS auf dem Ziel vorhanden ist). Tatsächlich können Sie iox als einfaches ShadowSocks verwenden.
Und iox bietet auch UDP-Verkehrsweiterleitung.
Natürlich, da iox in Go geschrieben ist, ist das statisch gelinkte Programm etwas groß, das Rohprogramm ist 2,2 MB (800 KB nach UPX-Kompression).
Sie können sehen, alle Parameter sind einheitlich. -l/--local bedeutet auf einem lokalen Port lauschen; -r/--remote bedeutet mit entferntem Host verbinden.
Hinweis: Ab v0.4 kann mit -l/--local angegeben werden, auf welcher IP gelauscht werden soll. Wenn nur Ports angegeben werden, ist der Standardwert 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` ist auch OK, aber nicht empfohlen. Weil `-l *:9999` (lauscht auf 0.0.0.0:9999 mit Verschlüsselung) mehrdeutig ist
Lauscht auf 0.0.0.0:8888 und 0.0.0.0:9999, leitet Verkehr zwischen 2 Verbindungen weiter
./iox fwd -l 8888 -l 9999
Lauscht auf 0.0.0.0:8888, leitet Verkehr zu 1.1.1.1:9999 weiter
./iox fwd -l 8888 -r 1.1.1.1:9999
Verbinde 1.1.1.1:8888 und 1.1.1.1:9999, leite zwischen 2 Verbindungen weiter
./iox fwd -r 1.1.1.1:8888 -r 1.1.1.1:9999
Starte Socks5-Server auf 0.0.0.0:1080
./iox proxy -l 1080
Starte Socks5-Server auf dem kontrollierten Host, leite dann zu VPS im Internet weiter
VPS leitet 0.0.0.0:9999 zu 0.0.0.0:1080
Sie müssen sie paarweise verwenden, da es ein einfaches Protokoll zur Steuerung des Rückverbindens enthält
./iox proxy -r 1.1.1.1:9999
./iox proxy -l 9999 -l 1080 // beachte, die beiden Ports sind in Reihenfolge
für ew:
./ew -s rcsocks -l 1080 -e 9999
./ew -s rssocks -d 1.1.1.1 -e 9999
Dann verbinde mit Intranet-Host
# proxychains.conf
# socks5://1.1.1.1:1080
$ proxychains rdesktop 192.168.0.100:3389
Zum Beispiel leiten wir Port 3389 im Intranet zu unserem VPS weiter
// kontrollierter Host
./iox fwd -r 192.168.0.100:3389 -r *1.1.1.1:8888 -k 656565
// unser VPS
./iox fwd -l *8888 -l 33890 -k 656565
Es ist leicht zu verstehen: Der Verkehr zwischen dem kontrollierten Host und unserem VPS:8888 wird verschlüsselt, der vorher geteilte geheime Schlüssel ist 'AAA', iox wird ihn verwenden, um Seed-Key und Nonce zu generieren (Normalerweise sollte Nonce nicht wiederverwendet werden. Aber da die Verschlüsselung von iox nur zur Umgehung von IDS dient, um keinen zusätzlichen Platz zuzuweisen, wird die TCP-Stream-Verschlüsselung die Nonce wiederverwenden), dann mit Xchacha20 verschlüsseln (ersetzt AES-CTR mit Xchacha20 in Version v0.3)
Daher sollte * paarweise verwendet werden
./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
Verwendung von iox als einfaches ShadowSocks
// ssserver
./iox proxy -l *9999 -k 000102
// sslocal
./iox fwd -l 1080 -r *VPS:9999 -k 000102
Muss nur die CLI-Option -u hinzufügen
./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
HINWEIS: Wenn Sie eine mehrstufige Verbindung herstellen, muss der Remote2Remote-UDP-Modus zuletzt gestartet werden, das ist der Befehl Nr. 3 im obigen Beispiel
UDP-Weiterleitung kann ein Verhalten zeigen, das nicht Ihren Erwartungen entspricht. Tatsächlich gibt es auf GitHub derzeit nur Beispiele für die Weiterleitung eines lokalen Listeners zu einem entfernten Host, daher kann ich sie nur nach meinem Verständnis implementieren.
Sie können den Grund im Quellcode finden. Wenn Sie Ideen haben, sind PRs / Issues willkommen.
Die MIT-Lizenz