Původní cíle v transparentním přeposílání TCP na SOCKS
Vysvětluje, proč transparentní přeposílání TCP na SOCKS potřebuje překladač, který obnoví původní cíl před vyjednáváním s proxy.
Brána firewall může změnit, kam připojení TCP dorazí. Samotnou touto změnou však nedokáže naučit původní aplikaci mluvit SOCKS.
Běžný server SOCKS očekává vyjednávání, které popisuje požadovaný cíl. Aplikace, která o proxy neví, místo toho okamžitě odešle vlastní bity protokolu. Přesměrujte tyto bity přímo na posluchač SOCKS a obě strany se rozejdou v názoru na první zprávu.
Chybějící součástí je překladač
Transparentní součást pro přenos TCP na proxy stojí mezi těmito rozhraními. Zjistí cíl, který aplikace původně požadovala, naváže odpovídající relaci SOCKS nebo HTTP CONNECT a poté přenáší data aplikace přes vzniklý tok.
Na své cestě přes Linux iptables získává zdrojový kód redsocks zachovaný cíl pomocí SO_ORIGINAL_DST. Jiné operační systémy a způsoby přesměrování používají odlišné mechanismy. To je vlastnost přesměrovávače a síťového nastavení, nikoli běžná funkce klienta SOCKS.
Informace o původním cíli také vysvětluje, proč přesunutí pravidla přesměrování z hostitele proxy na nesouvisející bránu není vždy rovnocenné. Přijímající proces potřebuje metadata, která vyžaduje jeho režim zachytávání. Adresa přepsaná jinde už nemusí tuto informaci poskytovat v očekávané podobě.
Udržujte rozsah překladače jasný. Fungující přesměrované připojení TCP nedokazuje podporu libovolného UDP, ICMP ani každé cesty překladače názvů. Protokol nadřazeného proxy a implementace překladače stále určují podporované operace.
Když nastavení selže hned po připojení, zkontrolujte hranici protokolu dříve, než rozšíříte pravidla přístupu. Dokonale dostupný posluchač SOCKS může odmítnout bity, které nikdy nebyly požadavkem SOCKS.