Un tallafoc pot canviar on acaba una connexió TCP. Però no pot, només amb aquest canvi, ensenyar l'aplicació d'origen a parlar SOCKS.

Un servidor SOCKS normal espera una negociació que descrigui la destinació sol·licitada. Una aplicació que no coneix el proxy envia en canvi els seus propis bytes de protocol immediatament. Redirigiu aquests bytes directament a un oient SOCKS i les dues bandes no es posaran d'acord sobre el primer missatge.

El component que falta és un traductor

Un component transparent de TCP a proxy se situa entre aquestes interfícies. Descobreix la destinació que l'aplicació havia sol·licitat originalment, estableix la sessió SOCKS o HTTP CONNECT adequada i després retransmet les dades de l'aplicació pel flux resultant.

En el seu camí de Linux iptables, el codi de redsocks recupera la destinació preservada mitjançant SO_ORIGINAL_DST. Altres sistemes operatius i mètodes de redirecció fan servir mecanismes diferents. Això és una propietat del redireccionador i de la configuració de xarxa, no una funció d'un client SOCKS corrent.

La informació de la destinació original també explica per què moure una regla de redirecció de l'amfitrió del proxy a una passarel·la no relacionada no sempre és equivalent. El procés receptor necessita les metadades que exigeix el seu mode d'intercepció. Una adreça reescrita en un altre lloc pot deixar de proporcionar aquesta informació en la forma esperada.

Mantingueu explícit l'abast del traductor. Una connexió TCP redirigida que funciona no demostra suport per a UDP arbitrari, ICMP o per a cada camí de resolució. El protocol del proxy superior i la implementació del traductor segueixen definint les operacions admeses.

Quan una configuració falla immediatament després de la connexió, comproveu la frontera del protocol abans d'ampliar les regles d'accés. Un oient SOCKS perfectament accessible pot rebutjar bytes que mai no van ser una sol·licitud SOCKS.

Articles relacionats