Redsocks lauscht auf Loopback, aber VPN-Verkehr kommt nie an
Ein Listener, der nur an Loopback gebunden ist, sieht niemals Verkehr, der von tun0 umgeleitet wird. Lesen Sie das Umleitungsziel und die Socket-Bindung, korrigieren Sie die Bindung und testen Sie dann von einem echten Client aus.
Ein Tunnel kommt hoch, der Client kann das Gateway anpingen, und jede Webanfrage über den Proxy-Pfad stirbt. Der redsocks-Prozess läuft und sein Port lauscht, also wirkt der Dienst vom Gateway selbst aus gesund. Was scheitert, ist der Zustellungsschritt: Ein vom Tunnel umgeleitetes Paket landet nicht auf dem Socket, den Sie gestartet haben. Die Bind-Adresse und das Umleitungsziel müssen übereinstimmen, und geprüft wird meist nur eines von beiden.
Wo ein umgeleitetes Paket tatsächlich landet
Transparentes Proxying auf einem Gateway nutzt ein REDIRECT in der nat-Tabelle unter PREROUTING, um das Ziel einer eingehenden Verbindung auf einen lokalen Port umzuschreiben. Das umgeschriebene Ziel ist eine lokale Adresse aus Sicht der Schnittstelle, auf der das Paket ankam, nicht die Loopback-Adresse eines Prozesses, der anderswo gestartet wurde. Ein Listener, der nur an 127.0.0.1 gebunden ist, nimmt Verbindungen an, die bereits lokal auf dem Host waren, und genau dieser Fall funktioniert weiter, während der Tunnelverkehr scheitert. Das Loopback des Clients selbst ist eine dritte Adresse und niemals das Ziel der Gateway-Regel.
Bevor Sie also die Zugangsdaten der Gegenstelle anfassen, stellen Sie zwei Tatsachen fest: auf welche lokale Adresse die Regel umschreibt und an welche Adresse der Proxy-Socket gebunden ist.
Lesen Sie Listener und Umleitungsregel zusammen
Geben Sie die Socket-Tabelle und die nat-Regeln im selben Durchgang aus, denn eine Regel, die auf einen Port zeigt, den niemand besitzt, sieht genauso aus wie eine Regel, die auf die falsche Adresse zeigt. sudo ss -ltnp | grep redsocks zeigt die Bind-Adresse und den besitzenden Prozess. sudo iptables -t nat -S PREROUTING zeigt das REDIRECT-Ziel, und sudo iptables -t nat -L PREROUTING -v -n zeigt, ob etwas darauf gepasst hat.
Ein Sprung in eine Benutzerkette namens REDSOCKS bewirkt nichts, wenn diese Kette nicht existiert und nicht die beabsichtigten Ausnahmen und die REDIRECT-Aktion trägt. Lesen Sie die Kette, in die gesprungen wird, mit sudo iptables -t nat -S REDSOCKS, statt anzunehmen, der Name erledige die Arbeit.
Vergleichen Sie dann die beiden Werte. Wenn die Regel auf eine Gateway-Adresse auf Port 12345 umleitet und der Listener 127.0.0.1:12345 meldet, erklärt die Abweichung das Scheitern ohne jede weitere Diagnose.
Binden Sie eng, dann begrenzen Sie, was es erreichen kann
Die Beispielkonfiguration der Gegenstelle setzt den Listener aus gutem Grund standardmäßig auf Loopback: Ein transparenter Proxy nimmt Verbindungen im Namen jedes Teilnehmers an, der ihn erreichen kann. Die Bindung auf 0.0.0.0 zu ändern behebt die Zustellung und öffnet gleichzeitig den Port auf jeder Schnittstelle, was eine Sicherheitsänderung ist, keine neutrale Reparatur. Binden Sie lieber an die konkrete lokale Adresse, die die Umleitung anvisiert, und halten Sie den Port auf nicht vertrauenswürdigen Schnittstellen geschlossen. Ist eine weitere Bindung unvermeidbar, fügen Sie eine Host-Firewall-Regel hinzu, die nur den Quellbereich des Tunnels und den eigenen lokalen Verkehr des Gateways erlaubt.
Den Port auf der öffentlichen Schnittstelle zu öffnen ist für umgeleiteten VPN-Verkehr nie nötig, weil die Verbindung nach dem Umschreiben lokal endet. Setzen Sie den Proxy nicht dem Internet aus, damit eine lokale Umleitung funktioniert.
Beweisen Sie es mit einer neuen Verbindung von einem Client
Testen Sie von einem echten VPN-Client mit einer frischen TCP-Verbindung, nicht aus einer Shell auf dem Gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com auf dem Client übt den umgeleiteten Pfad von Anfang bis Ende.
Bestätigen Sie dann, dass eine direkte Verbindung zum Listener aus einem nicht vertrauenswürdigen Netz weiterhin abgelehnt wird und dass die eigene Verbindung des Proxys nach oben nicht erneut von derselben Regel erfasst wird. Rekursives Abfangen zeigt sich als Proxy, der sich mit sich selbst verbindet und nie eine Anfrage abschließt. Nehmen Sie das Ziel des Proxys in die Ausschlussmenge auf oder markieren Sie seine ausgehenden Pakete, damit die Kette sie überspringt.
Denken Sie schließlich daran, was dieser Pfad nicht abdeckt. Gewöhnliche redsocks-TCP-Umleitung macht UDP, QUIC oder DNS nicht zu SOCKS-Verkehr, und private Ziele brauchen meist ausdrückliche Ausnahmen. Ein erfolgreicher lokaler Test beweist nur den Loopback-Pfad, der nie das Problem war.