Conectar clientes SOCKS a un padre HTTP CONNECT con 3proxy

La aplicación requiere SOCKS. El servicio ascendente aprobado acepta HTTP CONNECT. Poner el punto final HTTP en el campo SOCKS de la aplicación no traduce entre los protocolos.

Una puerta de enlace puede aceptar SOCKS de la aplicación, leer el destino solicitado y pedir al padre HTTP un túnel CONNECT hacia ese destino. Después retransmite el flujo de la aplicación por el túnel.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

Haz explícita cada interfaz

Para una puerta de enlace que admite esta disposición, importa su tipo de padre. La documentación de 3proxy distingue un padre connect de un padre usado como proxy de reenvío HTTP ordinario.

Con un usuario de 3proxy y una autenticación ya existentes, un fragmento de enrutamiento solo local puede adoptar esta forma:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

Este fragmento supone que la cuenta ya está definida. No añade credenciales que el propio padre HTTP requiera y no sustituye la política de acceso existente. Para destinos públicos en una ruta que permite un padre HTTP público sin autenticar, la lista de proxies HTTP ofrece candidatos de host y puerto. Mantén ausentes las credenciales del padre para esa rama y confirma el permiso para el destino real; la cuenta propia de la puerta de enlace sigue siendo local. La regla parent se asocia con la regla allow anterior según el modelo de configuración documentado de 3proxy.

La aplicación usa el punto final SOCKS local. La puerta de enlace usa HTTP CONNECT hacia el padre. El padre sigue decidiendo si se permiten el host y el puerto de destino solicitados.

El ámbito útil aquí es el túnel de flujo TCP ordinario. Una asociación UDP de SOCKS5 no pasa a estar admitida solo porque el escucha frontal acepte SOCKS5. Un padre HTTP CONNECT no proporciona automáticamente el repetidor UDP necesario.

HTTPS puede permanecer de extremo a extremo dentro de esta ruta; la traducción entre interfaces de proxy no exige suplantar el sitio web de destino. La autenticación en la puerta de enlace, la autenticación en el padre y la autenticación en el sitio web siguen siendo credenciales e intercambios distintos.