Traducir una solicitud SOCKS5 a un túnel HTTP

Un frontal SOCKS5 puede utilizar un proxy HTTP como su transporte posterior. Actúa como servidor SOCKS ante el cliente y como cliente HTTP CONNECT ante el padre. Los dos intercambios de control terminan antes de que comience el flujo de la aplicación.

La solicitud SOCKS CONNECT ya aporta el host o la dirección de destino y el puerto. Para un intercambio HTTP/1.1 ilustrativo con el padre:

client → adapter: SOCKS5 CONNECT service.example.net:443
adapter → parent:
    CONNECT service.example.net:443 HTTP/1.1
    Host: service.example.net:443

parent → adapter: HTTP/1.1 200 Connection Established
                 [end of headers]
adapter → client: SOCKS5 success reply

client ↔ adapter ↔ parent ↔ service: application bytes

Traduzca el resultado en el límite

El adaptador completa cualquier autenticación requerida por el padre y espera el resultado del CONNECT. Una respuesta 2xx correcta establece el túnel del padre. Solo entonces debe devolver la respuesta SOCKS de éxito correspondiente al cliente descendente.

Si el padre rechaza la operación, envíe una respuesta SOCKS de fallo definida y luego termine la conexión del cliente de inmediato. SOCKS5 exige ese cierre dentro de los diez segundos siguientes a la detección del fallo. Conserve el estado HTTP del padre como información de diagnóstico para el adaptador. Reenviar esa línea de estado como datos de aplicación introduciría un mensaje de control HTTP en un flujo cuyo cliente espera un encuadre SOCKS.

Antes de un resultado CONNECT correcto, el padre sigue hablando HTTP, incluido el encuadre de cualquier respuesta de desafío o de error. Tras el delimitador de cabeceras de un resultado correcto, la conexión pasa a ser el túnel; no hay ningún cuerpo de respuesta HTTP que consumir primero.

Conserve los bytes posteriores a las cabeceras

Una lectura puede contener a la vez el final de las cabeceras del padre y bytes procedentes del destino. Retenga esos bytes adicionales para la aplicación descendente. Los protocolos en los que el servidor habla primero pueden saludar en cuanto se abre su conexión.

Una vez enviada la respuesta SOCKS de éxito, retransmita el flujo de la aplicación en ambos sentidos. El adaptador no necesita alternar un mensaje de cliente con un mensaje de servidor, ni necesita entender los registros TLS para reenviarlos. Su trabajo de protocolo consistió en establecer y traducir las dos negociaciones de túnel.