Linux-Port-Weiterleitung an Socks-Proxy

Question

Ich habe ein Tutorial über ein Raspberry Pi-Projekt gelesen. Kurz gesagt, das Projekt besteht aus einer TOR-Middle-Box-AP, die über eine Ethernet-Schnittstelle mit dem Internet verbunden ist, und Clients können sich über ihre WiFi-Schnittstelle mit dem Raspberry Pi WLAN-Netzwerk verbinden. Der gesamte Verkehr, der zur WiFi-Schnittstelle kommt, wird mithilfe von iptables-Portweiterleitungsbefehlen zum lokalen TOR SOCKS-Proxy umgeleitet.

sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --syn -j REDIRECT --to-ports 9040 

Jetzt ist meine Frage, wie weiß der TOR Socks-Proxy den echten Socket-Zielport, wie von der Anwendung angefordert? Angenommen, ich verwende Firefox zum Öffnen von stackvoerflow.com. Firefox macht eine Anfrage an StackoverflowIP: 80 ..aber Iptables routet die Anfrage an localhost: 9050, weiß die Anwendung, dass es einen SOCKS-Proxy dazwischen gibt (unter der Annahme, dass die Proxy-Einstellungen NICHT in den Browser-Einstellungen eingestellt wurden)? Und wie kennt der TOR local SOCKS Proxy den realen Zielport, wenn der Zielport von iptables von 80 auf 9050 geändert wurde?

Answer 1

Es gibt eine Kernel-API (getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, (struct sockaddr*) &orig_addr, sizeof(orig_addr))), die für den Proxy verfügbar ist, um das tatsächlich angeforderte Ziel zu kennen.

A simple example daemon there

Durch die Art und Weise gibt es eine neue TProxy Ziel Methode, die als REDIRECT mächtiger ist (kann in beiden Richtungen transparent sein), aber erfordert zusätzliche Einstellungen (--tproxy-mark benötigte dann von ip rule fwmark ... und die Proxy verwendet nun setsockopt(fd, SOL_IP, IP_TRANSPARENT, &flag, sizeof(flag)) und dann verwendet mehr Standardmethoden als bei REDIRECT). Nicht für TOR erforderlich, aber neue Anwendungen verwenden REDIRECT möglicherweise nicht mehr.

TPROXY example