Un frontal SOCKS5 pode usar un proxy HTTP como o seu transporte posterior. Actúa como servidor SOCKS fronte ao cliente e como cliente HTTP CONNECT fronte ao pai. Os dous intercambios de control rematan antes de que comece o fluxo da aplicación.

A solicitude SOCKS CONNECT xa fornece o host ou o enderezo de destino e o porto. Para un intercambio HTTP/1.1 ilustrativo co pai:

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

Traduza o resultado na fronteira

O adaptador completa calquera autenticación requirida polo pai e agarda o resultado do CONNECT. Unha resposta 2xx correcta establece o túnel do pai. Só entón debe devolver a resposta SOCKS de éxito correspondente ao cliente descendente.

Se o pai rexeita a operación, envíe unha resposta SOCKS de fallo definida e despois remate a conexión do cliente de inmediato. SOCKS5 esixe ese peche dentro dos dez segundos seguintes á detección do fallo. Conserve o estado HTTP do pai como información de diagnóstico para o adaptador. Reenviar esa liña de estado como datos da aplicación introduciría unha mensaxe de control HTTP nun fluxo cuxo cliente espera unha estruturación SOCKS.

Antes dun resultado CONNECT correcto, o pai aínda fala HTTP, incluída a estruturación de calquera resposta de desafío ou de erro. Tras o delimitador de cabeceiras dun resultado correcto, a conexión pasa a ser o túnel; non hai ningún corpo de resposta HTTP que consumir primeiro.

Conserve os bytes posteriores ás cabeceiras

Unha lectura pode conter á vez o final das cabeceiras do pai e bytes procedentes do destino. Retéñanos eses bytes adicionais para a aplicación descendente. Os protocolos nos que o servidor fala primeiro poden saudar en canto se abre a súa conexión.

Unha vez enviada a resposta SOCKS de éxito, retransmita o fluxo da aplicación en ambos os sentidos. O adaptador non necesita alternar unha mensaxe de cliente cunha mensaxe de servidor, nin necesita entender os rexistros TLS para reenvialos. O seu traballo de protocolo consistiu en establecer e traducir as dúas negociacións de túnel.

Artigos relacionados