Oorspronkelijke bestemmingen bij transparante TCP-naar-SOCKS-doorsturing

Een firewall kan veranderen waar een TCP-verbinding belandt. Met die verandering alleen kan hij de oorspronkelijke toepassing niet leren SOCKS te spreken.

Een gewone SOCKS-server verwacht een onderhandeling die de gevraagde bestemming beschrijft. Een toepassing die de proxy niet kent, stuurt in plaats daarvan meteen zijn eigen protocolbytes. Leid die bytes rechtstreeks naar een SOCKS-listener en de twee kanten zijn het oneens over het eerste bericht.

Het ontbrekende onderdeel is een vertaler

Een transparant TCP-naar-proxy-onderdeel zit tussen die interfaces. Het achterhaalt de bestemming die de toepassing oorspronkelijk aanvroeg, brengt de juiste SOCKS- of HTTP CONNECT-sessie tot stand en geeft daarna de toepassingsgegevens door over de ontstane stroom.

Op zijn Linux iptables-pad haalt de redsocks-bron de bewaarde bestemming op met SO_ORIGINAL_DST. Andere besturingssystemen en omleidingsmethoden gebruiken andere mechanismen. Dit is een eigenschap van de omleider en de netwerkopstelling, geen gewone functie van een SOCKS-client.

Informatie over de oorspronkelijke bestemming verklaart ook waarom het verplaatsen van een omleidingsregel van de proxyhost naar een ongerelateerde gateway niet altijd gelijkwaardig is. Het ontvangende proces heeft de metadata nodig die zijn onderscheppingswijze vereist. Een elders herschreven adres levert die informatie misschien niet meer in de verwachte vorm.

Houd de reikwijdte van de vertaler expliciet. Een werkende omgeleide TCP-verbinding bewijst geen ondersteuning voor willekeurige UDP, ICMP of elk resolverpad. Het protocol van de bovenliggende proxy en de implementatie van de vertaler bepalen nog steeds de ondersteunde bewerkingen.

Als een opstelling direct na de verbinding mislukt, controleer dan de protocolgrens voordat je toegangsregels verruimt. Een volkomen bereikbare SOCKS-listener kan bytes weigeren die nooit een SOCKS-verzoek waren.