Leiten Sie den HTTP-Verkehr von der LAN-Box an einen externen Proxy um, indem Sie iptables auf meinem Router verwenden

988
ccampo

Mein Ziel ist es, alle HTTP-Anforderungen von einer einzigen IP (meinem Laptop 192.168.1.134) in meinem LAN an eine externe IP (Internet-VPS, sagen wir X.X.X.X), die einen Proxy-Server ausführt (speziell mitmproxyim transparenten Modus ausgeführt), den Port 80 zu überwachen.

Mein Heim-LAN wird von einem ASUS RT-N66U-Router mit Asuswrt-Merlin-Firmware betrieben. Der Router hat eine IP-Adresse 192.168.1.1und ist das Standard-Gateway für jedes Gerät in meinem Netzwerk. Um den Datenverkehr weiterzuleiten, habe ich ssh'd an meinen Router gesendet und die folgenden iptablesBefehle ausgeführt:

iptables -t nat -A PREROUTING -s 192.168.1.134 -p tcp --dport 80 -j DNAT --to X.X.X.X:80 iptables -t nat -A POSTROUTING -j MASQUERADE

Außerdem ist die IP-Weiterleitung auf meinem Router aktiviert:

admin@RT-N66U:/tmp/home/root# cat /proc/sys/net/ipv4/ip_forward 1

Das führt zu etwas, aber ich erwarte es nicht. Von 192.168.1.134(meinem Laptop) aus kann ich, wenn ich eine einfache http-Anfrage mache (z. B. curl http://example.com), im Ereignisprotokoll meines Proxys erkennen, dass mitmproxyein Client eine Verbindung hergestellt hat (unter Verwendung der öffentlichen IP-Adresse meines Routers, die von meinem ISP ausgestellt wurde) das ist ungefähr so ​​weit wie es geht. Es geht nie weiter und mein Curl-Befehl wartet nur. Schließlich sehe ich im Protokoll meines Proxys "Verbindung zurückgesetzt durch Peer" und die Verbindung wird geschlossen.

Jede Hilfe wird vorgeschlagen. Ich muss zugeben, ich bin nicht sehr gut darin iptables.

1
Vermutlich weil mitmproxy im transparenten Modus auf dem Router ausgeführt werden soll, erhält er daher spezifische Informationen von iptables (siehe http://docs.mitmproxy.org/de/latest/transparent/linux.html). Dies funktioniert nicht, wenn die Umleitung zuvor erfolgt ist: Das Ziel ist verloren. ODER Sie müssen einfach mitmproxy "Dinge erledigen" (bearbeiten, akzeptieren ...) A.B vor 7 Jahren 0
@AB Ich sollte beachten, dass ich dies erfolgreich zum Laufen gebracht habe, wenn sich die Proxy-Box im LAN befindet, z. B. ein Raspberry PI. Es hat etwas damit zu tun, dass sich die Proxy-Box im WAN befindet. ccampo vor 7 Jahren 0
Ich stehe zu dem, was ich gesagt habe. http://docs.mitmproxy.org/de/latest/howmitmproxy.html#transparent-http quoting: "Der erste ist ein Umleitungsmechanismus, der eine TCP-Verbindung, die für einen Server im Internet bestimmt ist, transparent an einen abhörenden Proxyserver weiterleitet In der Regel handelt es sich um eine ** Firewall auf demselben Host wie der Proxyserver ** - iptables unter Linux "und" Der Routing-Mechanismus, der die Umleitung durchgeführt hat ** verfolgt das ursprüngliche Ziel für uns ** ". Diese Informationen gingen verloren. Sie können es mit einem Tunnel zwischen Ihrem gw und mitmproxy arbeiten lassen und nur auf dem Proxy umleiten. A.B vor 7 Jahren 0
Übrigens ist die moderne Methode die Verwendung von TPROXY, REDIRECT bleibt akzeptabel (das erwartet man mitmproxy, also keine andere Wahl) und DNAT kann überhaupt nicht funktionieren: Das ursprüngliche Ziel geht außerhalb des Routers verloren. A.B vor 7 Jahren 0
@AB ist nicht sicher, ob Sie dem folgen, was ich sage, aber ich habe den transparenten Modus aktiviert, wenn sich der Proxy auf einer anderen Box neben dem Router befand, nur innerhalb des LANs. Siehe das Beispiel: https://gist.github.com/ccampo133/755b45e966dc736f71137e049ed5f0c8 Vergessen Sie mitmproxy, vergessen Sie den transparenten Modus selbst. Vergessen Sie alle mitm-spezifischen Details. Reden Sie Reverse Proxy. Es kann Nginx sein. Der Punkt ist, dass es immer noch nicht funktioniert, wenn sich der Proxy im WAN und nicht im LAN befindet, und ich möchte wissen, ob es möglich ist, dass es funktioniert. ccampo vor 7 Jahren 0
`ip route add default über 192.168.1.139 dev br0 table 2` verliert die Ziel-IP nicht. `iptables -t nat -A PREROUTING -s 192.168.1.134 -p tcp --dport 80 -j DNAT --bis XXXX: 80` tut es. Beide leiten zum Proxy weiter. Der erste behält die ursprüngliche Ziel-IP und der Proxy weiß, wo er seine Arbeit fortsetzen kann, der zweite nicht, der Proxy hat keine Ahnung, was als nächstes zu tun ist. Das Beste, was es für HTTP tun kann, ist den Host-Header aufzulösen: langsam und für mitm unzuverlässig. Ok, Sie können die Weiterleitung an einem anderen Ort durchführen lassen, aber der Proxy muss der nexthop des Routers sein. Mit einem Tunnel zum Proxy ist es noch möglich. A.B vor 7 Jahren 0
Ich weiß es nicht für Nginx, aber ich denke, dass Squid im Accel-Modus für HTTP mit Ihrer aktuellen Einstellung funktioniert (durch Auflösen des Host-Headers). A.B vor 7 Jahren 0
also stimmst du zu? A.B vor 7 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme