Ursprungliga destinationer i transparent TCP-till-SOCKS-vidarebefordran

En brandvägg kan ändra var en TCP-anslutning landar. Men med bara den ändringen kan den inte lära den ursprungliga applikationen att tala SOCKS.

En vanlig SOCKS-server väntar sig en förhandling som beskriver den begärda destinationen. En applikation som inte känner till proxyn skickar i stället genast sina egna protokollbyte. Omdirigera de byten rakt till en SOCKS-lyssnare och de två sidorna är oense om det första meddelandet.

Den saknade komponenten är en översättare

En transparent TCP-till-proxy-komponent sitter mellan dessa gränssnitt. Den tar reda på destinationen som applikationen ursprungligen begärde, upprättar lämplig SOCKS- eller HTTP CONNECT-session och vidarebefordrar sedan applikationsdata över den uppkomna strömmen.

På sin Linux iptables-väg hämtar redsocks-källan den bevarade destinationen med hjälp av SO_ORIGINAL_DST. Andra operativsystem och omdirigeringsmetoder använder andra mekanismer. Detta är en egenskap hos omdirigeraren och nätverksuppsättningen, inte en vanlig SOCKS-klientfunktion.

Informationen om den ursprungliga destinationen förklarar också varför det inte alltid är likvärdigt att flytta en omdirigeringsregel från proxyvärden till en orelaterad gateway. Den mottagande processen behöver de metadata som dess avlyssningssätt kräver. En adress som skrivits om någon annanstans ger kanske inte längre den informationen i förväntad form.

Håll översättarens omfattning tydlig. En fungerande omdirigerad TCP-anslutning bevisar inte stöd för godtycklig UDP, ICMP eller varje resolverväg. Uppströms proxyprotokoll och översättarens implementering definierar fortfarande de stödda operationerna.

När en uppsättning misslyckas direkt efter anslutningen, kontrollera protokollgränsen innan du utökar åtkomstreglerna. En fullt nåbar SOCKS-lyssnare kan avvisa byte som aldrig var en SOCKS-begäran.