Destinos orixinais no reenvío transparente de TCP a SOCKS
Explica por que o reenvío transparente de TCP a SOCKS necesita un tradutor que recupere o destino orixinal antes de negociar co proxy.
Un devasado pode cambiar onde remata unha conexión TCP. Pero non pode, só con ese cambio, ensinar á aplicación de orixe a falar SOCKS.
Un servidor SOCKS corrente espera unha negociación que describa o destino solicitado. Unha aplicación que descoñece o proxy envía en cambio os seus propios bytes de protocolo de inmediato. Redirixa eses bytes directamente a un oínte SOCKS e as dúas partes discordarán sobre a primeira mensaxe.
O compoñente que falta é un tradutor
Un compoñente transparente de TCP a proxy sitúase entre esas interfaces. Descobre o destino que a aplicación solicitara orixinalmente, establece a sesión SOCKS ou HTTP CONNECT axeitada e despois retransmite os datos da aplicación polo fluxo resultante.
Na súa ruta de Linux iptables, o código de redsocks recupera o destino preservado mediante SO_ORIGINAL_DST. Outros sistemas operativos e métodos de redirección usan mecanismos distintos. Isto é unha propiedade do redireccionador e da configuración de rede, non unha función dun cliente SOCKS corrente.
A información do destino orixinal tamén explica por que mover unha regra de redirección do host do proxy a unha pasarela non relacionada non sempre é equivalente. O proceso receptor necesita os metadatos que esixe o seu modo de interceptación. Un enderezo reescrito noutro lugar pode que xa non proporcione esa información na forma agardada.
Manteña explícito o alcance do tradutor. Unha conexión TCP redirixida que funciona non demostra soporte para UDP arbitrario, ICMP nin para cada ruta de resolución. O protocolo do proxy superior e a implementación do tradutor seguen definindo as operacións admitidas.
Cando unha configuración falla xusto despois da conexión, revise o límite do protocolo antes de ampliar as regras de acceso. Un oínte SOCKS perfectamente accesible pode rexeitar bytes que nunca foron unha solicitude SOCKS.