Ich verwende einen TP-Link TL-WR1043ND- Router mit OpenWrt und Gargoyle . Ich möchte den gesamten Verkehr von meinem lokalen Netzwerk (vom Router bedient) transparent an einen Remote-Server weiterleiten. Im Wesentlichen wie ein Socken-Proxy würde funktionieren, nur ohne die verbundenen Client-Maschinen für Proxy konfigurieren zu müssen.
Ich habe gelesen, dass sshuttle der Weg für diese Art von Anforderung ist. Nach vielem Fummeln habe ich es endlich geschafft, alle Voraussetzungen zu erfüllen, und ich kann sshuttle ohne Fehlermeldungen wie diese starten:
./sshuttle --dns -vvr XXXXXX@YY.YY.YY.YY 0/0 Wo XXXXXX meine Benutzername auf einem Remote - Server YY.YY.YY.YY sshuttle ist ganz gut, keine Fehlermeldungen zu initialisieren scheinen, fügen alle notwendigen Regeln zu iptables, doch nach dem lokalen Proxy eingerichtet ist, ich bin nicht in der Lage zu verbinden überall aus mein lokales Netzwerk Dies ist die Ausgabe von sshuttle:
Starting sshuttle proxy. Binding: 12300 Listening on ('127.0.0.1', 12300). DNS listening on ('127.0.0.1', 12300). firewall manager ready. c : connecting to server... c : executing: ['ssh', 'XXXXXX@YY.YY.YY.YY', '--', 'P=python2; $P -V 2>/dev/null || P=python; exec "$P" -c \'import sys; skip_imports=1; verbosity=2; exec compile(sys.stdin.read(764), "assembler.py", "exec")\''] c : > channel=0 cmd=PING len=7 (fullness=0) WARNING: Ignoring unknown argument '--' XXXXXX@YY.YY.YY.YY's password: server: assembling 'cmdline_options.py' (29 bytes) server: assembling 'helpers.py' (914 bytes) server: assembling 'ssubprocess.py' (13668 bytes) server: assembling 'ssnet.py' (5446 bytes) server: assembling 'hostwatch.py' (2270 bytes) server: assembling 'server.py' (2370 bytes) s: latency control setting = True s: available routes: s: 69.64.32.0/22 s: > channel=0 cmd=PING len=7 (fullness=0) c : connected. Connected. c : Waiting: 3 r=[3, 5, 9] w=[9] x=[] (fullness=7/0) c : Ready: 3 r=[] w=[9] x=[] c : mux wrote: 15/15 c : Waiting: 3 r=[3, 5, 9] w=[] x=[] (fullness=7/0) s: > channel=0 cmd=ROUTES len=14 (fullness=7) s: Waiting: 1 r=[4] w=[5] x=[] (fullness=21/0) s: Ready: 1 r=[] w=[5] x=[] s: mux wrote: 15/15 s: mux wrote: 22/22 s: Waiting: 1 r=[4] w=[] x=[] (fullness=21/0) c : Ready: 3 r=[9] w=[] x=[] c : < channel=0 cmd=PING len=7 c : > channel=0 cmd=PONG len=7 (fullness=7) c : < channel=0 cmd=ROUTES len=14 firewall manager: starting transproxy. s: Ready: 1 r=[4] w=[] x=[] s: < channel=0 cmd=PING len=7 s: > channel=0 cmd=PONG len=7 (fullness=21) s: mux wrote: 15/15 s: Waiting: 1 r=[4] w=[] x=[] (fullness=28/0) >> iptables -t nat -N sshuttle-12300 >> iptables -t nat -F sshuttle-12300 >> iptables -t nat -I OUTPUT 1 -j sshuttle-12300 >> iptables -t nat -I PREROUTING 1 -j sshuttle-12300 >> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp >> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300 -m ttl ! --ttl 42 >> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 127.0.0.1/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42 c : mux wrote: 15/15 c : < channel=0 cmd=PONG len=7 c : received PING response c : Waiting: 3 r=[3, 5, 9] w=[] x=[] (fullness=0/0) s: Ready: 1 r=[4] w=[] x=[] s: < channel=0 cmd=PONG len=7 s: received PING response s: Waiting: 1 r=[4] w=[] x=[] (fullness=0/0) Ich habe keine Ahnung, wie ich dieses Problem überhaupt debuggen kann. Wenn ich sshuttle stoppe, werden die iptables-Regeln entfernt und die Netzwerkverbindungen funktionieren wieder:
firewall manager: undoing changes. >> iptables -t nat -D OUTPUT -j sshuttle-12300 >> iptables -t nat -D PREROUTING -j sshuttle-12300 >> iptables -t nat -F sshuttle-12300 >> iptables -t nat -X sshuttle-12300 c : c : Keyboard interrupt: exiting. Hat jemand es geschafft, eine funktionierende sshuttle-Instanz auf openwrt einzurichten? Oder gibt es einen anderen Weg, um das zu erreichen, was ich hier brauche (transparenter Proxy auf einem openwrt-Router)?
Verwandte und nicht beantwortete Frage: sshuttle auf einem DD-WRT / OpenWRT-Router
Glücklicherweise erhielt ich bei der sshuttle google-Gruppe eine Antwort vom Autor von sshuttle. Er schrieb:
Möglicherweise müssen Sie '-l 0.0.0.0' (das ist ein Kleinbuchstabe L) hinzufügen, um sshuttle anzuweisen, auf Verbindungen von Localhost (dem Router selbst) zu warten. Aus Sicherheitsgründen leitet sshuttle den Datenverkehr anderer Personen nicht standardmäßig weiter.
Und es funktioniert perfekt! Benutzen:
./sshuttle -l 0.0.0.0 --dns -vvr XXXXXX@YY.YY.YY.YY 0/0
Ein paar Dinge, die mich in die Quere kamen:
Ab Lager OpenWRT 12.09 AA müssen Sie folgende Pakete installieren:
python (verbraucht bei Abhängigkeiten 3-4 MB Flash)iptables-mod-nat-extraiptables-mod-ipoptUm SSH mit einem SSH-Schlüssel auf den Remote-Server zu übertragen, müssen Sie einen Dropbear-Formatschlüssel erstellen:
dropbearkey -t rsa -f /root/.ssh/id_rsa Geben Sie schließlich die Schlüsselposition in der sshuttleBefehlszeile an:
./sshuttle -e "ssh -i /root/.ssh/id_rsa" -l 0.0.0.0 -r xxxxxx@yy.yy.yy.yy 0/0 -vv --dns Bei einem GL-AR300M-Router, auf dem OpenWrt Chaos Calmer 15.05 ausgeführt wird, scheint die Vorgehensweise etwas anders zu sein als bei @trapezoid. Vielleicht ist es nicht ganz auf Lager OpenWRT (ich habe es nach dem Kauf nicht neu installiert) oder es ist nur der Zeitablauf.
Ich habe die Pakete installiert, die sie benannten, dh python iptables-mod-nat-extra iptables-mod-ipopt.
Damit das ssh-Schlüssel-basierte Login funktioniert, musste ich keinen speziellen ssh-Schlüssel generieren. Mein gewöhnlicher war genug, aber der autorized_keysmuss verschoben werden /etc/dropbear/( ssh-copy-iddh er wurde nicht in das richtige Verzeichnis verschoben ).