stringtranslate.com

Túnel HTTP

La tunelización HTTP se utiliza para crear un enlace de red entre dos ordenadores en condiciones de conectividad de red restringida, incluidos cortafuegos , NAT y ACL , entre otras restricciones. El túnel lo crea un intermediario llamado servidor proxy que suele estar ubicado en una DMZ .

La tunelización también puede permitir la comunicación mediante un protocolo que normalmente no sería compatible con la red restringida.

Método HTTP CONNECT

La forma más común de tunelización HTTP es el método HTTP CONNECT estandarizado. [1] [2] En este mecanismo, el cliente solicita a un servidor proxy HTTP que reenvíe la conexión TCP al destino deseado. Luego, el servidor procede a realizar la conexión en nombre del cliente. Una vez que el servidor ha establecido la conexión, el servidor proxy continúa enviando el flujo TCP hacia y desde el cliente. Solo la solicitud de conexión inicial es HTTP; después de eso, el servidor simplemente envía por proxy la conexión TCP establecida.

Este mecanismo es el que utiliza un cliente detrás de un proxy HTTP para acceder a sitios web mediante SSL o TLS (es decir, HTTPS). Los servidores proxy también pueden limitar las conexiones permitiendo únicamente conexiones al puerto HTTPS predeterminado 443, incluyendo hosts en la lista blanca o bloqueando el tráfico que no parezca SSL.

Ejemplo de negociación

El cliente se conecta al servidor proxy y solicita la tunelización especificando el puerto y el equipo host al que desea conectarse. El puerto se utiliza para indicar el protocolo que se solicita. [3]

CONECTAR  streamline.t-mobile.com:22  HTTP / 1.1 Autorización de proxy :  credenciales codificadas básicas

Si se permitió la conexión y el proxy se conectó al host especificado, entonces el proxy devolverá una respuesta de éxito 2XX. [3]

HTTP / 1.1  200  OK

Ahora, el cliente se está enviando mediante proxy al host remoto. Todos los datos enviados al servidor proxy se reenvían, sin modificaciones, al host remoto [3] y el cliente puede comunicarse mediante cualquier protocolo aceptado por el host remoto. En el ejemplo siguiente, el cliente está iniciando comunicaciones SSH, como lo indica el número de puerto en la solicitud CONNECT inicial.

SSH-2.0-OpenSSH_4.3\r\n...

Túnel HTTP sin utilizar CONNECT

También se puede implementar un túnel HTTP utilizando únicamente los métodos HTTP habituales, como POST, GET, PUT y DELETE. Esto es similar al enfoque utilizado en flujos bidireccionales sobre HTTP sincrónico ( BOSH ).

Un servidor HTTP especial se ejecuta fuera de la red protegida y un programa cliente se ejecuta en una computadora dentro de la red protegida. Siempre que se transmite tráfico de red desde el cliente, el cliente reempaqueta los datos de tráfico como una solicitud HTTP y retransmite los datos al servidor externo, que extrae y ejecuta la solicitud de red original para el cliente. La respuesta a la solicitud, enviada al servidor, se reempaqueta luego como una respuesta HTTP y se retransmite de vuelta al cliente. Dado que todo el tráfico está encapsulado dentro de solicitudes y respuestas GET y POST normales, este enfoque funciona a través de la mayoría de los servidores proxy y cortafuegos. [a]

Véase también

Notas

  1. ^ "Bridge: un reenvío de puertos dinámico sobre HTTP (con soporte de PROXY HTTP)". GitHub .

Referencias

  1. ^ Fielding, R. (junio de 1999). "Definiciones de métodos, CONNECT". Protocolo de transferencia de hipertexto -- HTTP/1.1. IETF . pág. 56. sec. 9.9. doi : 10.17487/RFC2616 . RFC 2616 . Consultado el 9 de julio de 2010 .
  2. ^ Khare, R.; Lawrence, S. (2000). "Actualización a TLS dentro de HTTP/1.1 (RFC 2817)". doi : 10.17487/RFC2817 . RFC 2817 . Consultado el 3 de julio de 2011 .  {{cite journal}}: Requiere citar revista |journal=( ayuda )
  3. ^ abc "CONNECT". HTTP/1.1 Semántica y contenido. IETF . Junio ​​de 2014. pág. 30. sec. 4.3.6. doi : 10.17487/RFC7231 . RFC 7231 . Consultado el 4 de noviembre de 2017 .