Ursprüngliche Ziele bei transparenter TCP-zu-SOCKS-Weiterleitung
Erklärt, warum transparente TCP-zu-SOCKS-Weiterleitung einen Übersetzer braucht, der das ursprüngliche Ziel wiederherstellt, bevor mit dem Proxy verhandelt wird.
Eine Firewall kann ändern, wo eine TCP-Verbindung landet. Allein durch diese Änderung kann sie die ursprüngliche Anwendung jedoch nicht lehren, SOCKS zu sprechen.
Ein gewöhnlicher SOCKS-Server erwartet eine Aushandlung, die das angeforderte Ziel beschreibt. Eine Anwendung, die den Proxy nicht kennt, sendet stattdessen sofort ihre eigenen Protokollbytes. Leite diese Bytes direkt an einen SOCKS-Listener weiter, und beide Seiten sind sich über die erste Nachricht uneinig.
Die fehlende Komponente ist ein Übersetzer
Eine transparente TCP-zu-Proxy-Komponente sitzt zwischen diesen Schnittstellen. Sie ermittelt das Ziel, das die Anwendung ursprünglich angefordert hat, baut die passende SOCKS- oder HTTP CONNECT-Sitzung auf und leitet anschließend die Anwendungsdaten über den entstandenen Strom weiter.
Auf ihrem Linux-iptables-Pfad ruft die redsocks-Quelle das erhaltene Ziel über SO_ORIGINAL_DST ab. Andere Betriebssysteme und Umleitungsverfahren verwenden andere Mechanismen. Das ist eine Eigenschaft des Umleiters und des Netzwerkaufbaus, keine gewöhnliche Funktion eines SOCKS-Clients.
Die Information über das ursprüngliche Ziel erklärt auch, warum das Verschieben einer Umleitungsregel vom Proxy-Host auf ein unabhängiges Gateway nicht immer gleichwertig ist. Der empfangende Prozess benötigt die Metadaten, die sein Abfangmodus voraussetzt. Eine anderswo umgeschriebene Adresse liefert diese Information womöglich nicht mehr in der erwarteten Form.
Halte den Geltungsbereich des Übersetzers ausdrücklich fest. Eine funktionierende umgeleitete TCP-Verbindung belegt keine Unterstützung für beliebiges UDP, ICMP oder jeden Resolver-Pfad. Das vorgelagerte Proxy-Protokoll und die Umsetzung des Übersetzers bestimmen weiterhin die unterstützten Operationen.
Wenn ein Aufbau unmittelbar nach dem Verbindungsaufbau scheitert, prüfe die Protokollgrenze, bevor du Zugriffsregeln erweiterst. Ein vollkommen erreichbarer SOCKS-Listener kann Bytes zurückweisen, die nie eine SOCKS-Anforderung waren.