¿Cual es la diferencia entre un proxy y un tunel de red?

[Usuario887]

Se conoce como túnel o tunneling a la técnica que consiste en encapsular un protocolo de red sobre otro (protocolo de red encapsulador) creando un túnel de información dentro de una red de computadoras.

https://es.wikipedia.org/wiki/T%C3%BAnel_(inform%C3%A1tica)

¿A que se refiere exactamente con 'encapsular un protocolo'? ¿Como puede encapsularse un protocolo sobre otro? Lo unico que se me viene a la mente es un cast de estructuras de C 

Saludos...

[kub0x]

Tunneling es un concepto para denotar que un protocolo puede encapsular la información de otro, normalmente para bypassear reglas de Firewall.

Un ejemplo claro es si sólo podemos hacer uso de conexiones que utilicen el puerto 80,443,25,21,53... Entonces como puedo conectarme a un servicio, ej: Spotify??

Pues el cliente (TU) y el servidor negociais una conexión por HTTPs y tunelas las peticiones hacia el servicio de Spotify por ahí. Luego el servidor, tiene que hablar el mismo idioma, por lo tanto ha de "empaquetar" o "encapsular" las respuestas del servicio en paquetes HTTP over TLS (HTTPS).

Otro claro ejemplo, y muy visto en Internet es el tunelado por SSH, piensa que estás encapsulando paquetes pertenecientes a otros protocolos.

En cambio un proxy es un forwarder, reenvia el tráfico al destino y al origen. El Proxy utilizará el protocolo que le convenga, y tu estarás restringido al uso de dicho protocolo.

Saludos.

[Usuario887]

Pues el cliente (TU) y el servidor negociais una conexión por HTTPs y tunelas las peticiones hacia el servicio de Spotify por ahí. Luego el servidor, tiene que hablar el mismo idioma, por lo tanto ha de "empaquetar" o "encapsular" las respuestas del servicio en paquetes HTTP over TLS (HTTPS).

El header del protocolo TCP:

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            TCP Header Format

El header del protocolo IP:

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

¿Como "encapsulo" al protocolo IP "dentro" del protocolo TCP o viceversa? 

[kub0x]

Pero TCP no representa un paquete en su totalidad. Piensa que una trama TCP/IP completa contiene la capa de aplicación, donde realmente están los datos que el cliente envía.

Por lo tanto, puedo enviar mediante HTTPS datos asociados a otro protocolo i.e SMTP, para luego el servidor extraerlos, y formar el paquete SMTP correcto.

De todas formas existen mas técnicas pues los payload se pueden usar para eludir firewalls pero no lo considero tunnelling.

[Usuario887]

Pero TCP no representa un paquete en su totalidad. Piensa que una trama TCP/IP completa contiene la capa de aplicación, donde realmente están los datos que el cliente envía.

Supuse que te referias a eso por un minuto... pero quise saber propiamente a que te referias.
¿Entonces solamente protocolos que funcionan en la capa de aplicacion (supongo que te refieres al modelo OSI) pueden "hacerse casting mutuamente", por decirlo asi, cosa que se llama tunneling?

De todas formas existen mas técnicas pues los payload se pueden usar para eludir firewalls

¿Para eludir firewalls en que sentido? ¿Se puede usar la tecnica para evitar que un firewall detecte una escucha en el puerto 443 con otro fin mas que la negociacion de paquetes HTTP?

[kub0x]

Supuse que te referias a eso por un minuto... pero quise saber propiamente a que te referias.
¿Entonces solamente protocolos que funcionan en la capa de aplicacion (supongo que te refieres al modelo OSI) pueden "hacerse casting mutuamente", por decirlo asi, cosa que se llama tunneling?

¿Para eludir firewalls en que sentido? ¿Se puede usar la tecnica para evitar que un firewall detecte una escucha en el puerto 443 con otro fin mas que la negociacion de paquetes HTTP?

Sé que esto te va a volver loco, pero puedo tunelar TCP over UDP si quisiera. No tiene porque ser siempre un protocolo de aplicación encapsulado en otro de aplicación.

Piensa que tendríamos en los datos enviados en la trama UDP el paquete TCP completo. Por lo tanto el servidor recibe el paquete UDP, toma los datos, los cuales son un paquete TCP con origen/destino etc y forma una trama completa TCP/IP con ese paquete TCP para enviarlo al destino.

Es decir, TCP en UDP -> envió al tunel -> Desempaqueta el UDP y forma una trama completa sobre TCP -> el server del tunnel la envía al destino

Sobre eludir firewalls, el tunneling de por hecho se utiliza para esto. A lo que yo me refería es algo más liviano. Existen protocolos de red con el campo payload. Ahí podríamos "inyectar" nuestro mensaje para el destino sin tener que encapsular o hacer uso del tunneling, todo depende de como actue el Firewall.

Saludos.

[Usuario887]

Es decir que el paquete TCP iria en el campo de datos del paquete UDP, ¿No?. Madre mia que interesante...

¿Sabes como podria experimentar esto? quiero decir... puedes experimentar la criptografia programando o haciendo calculos, pero ¿Hay alguna forma de depurar estos protocolos? Quiero decir verlos como ves el ensamblador de un programa, aunque este escrito en un lenguaje de alto nivel, con un depurador.

Y segun esta logica, un protocolo puede ser encapsulado en otro siempre que se encuentren en la misma capa en terminos del modelo OSI, ¿No? porque no podrias, por ejemplo, encapsular a TCP en HTTP porque en primer lugar HTTP necesita a TCP para funcionar... ¿O si?

[kub0x]

Es decir que el paquete TCP iria en el campo de datos del paquete UDP, ¿No?. Madre mia que interesante...

¿Sabes como podria experimentar esto? quiero decir... puedes experimentar la criptografia programando o haciendo calculos, pero ¿Hay alguna forma de depurar estos protocolos? Quiero decir verlos como ves el ensamblador de un programa, aunque este escrito en un lenguaje de alto nivel, con un depurador.

Y segun esta logica, un protocolo puede ser encapsulado en otro siempre que se encuentren en la misma capa en terminos del modelo OSI, ¿No? porque no podrias, por ejemplo, encapsular a TCP en HTTP porque en primer lugar HTTP necesita a TCP para funcionar... ¿O si?

Me alegro de que te hagas preguntas, veo que lo vas pillando, pero hay que remarcar un par de cosas.

Existe una forma determinista de experimientar esto, y es programando y depurando con un capturador de paquetes de red ya sea TCPDump o Wireshark.

Y segun esta logica, un protocolo puede ser encapsulado en otro siempre que se encuentren en la misma capa en terminos del modelo OSI, ¿No? porque no podrias, por ejemplo, encapsular a TCP en HTTP porque en primer lugar HTTP necesita a TCP para funcionar... ¿O si?

Un paquete de red se compone en una serie de tramas. Cuando recibes un paquete vía Socket estás recibiendo un paquete TCP o UDP. Dentro de esté en el campo de datos está el paquete HTTP embebido. Por lo tanto tunelar TCP por HTTP, requeriría que en el campo de datos del paquete TCP esté el paquete HTTP, que el servidor extraiga el paquete HTTP y finalmente como este contiene otro paquete TCP lo enviaría al destino. Así que sí que se podría.

Lo que quiero que quede claro es que tu PC recibe unas tramas y te muestra el paquete TCP/UDP si tu socket maneja paquetes TCP o UDP(datagramas) y en el campo de datos vendrían los paquetes de la capa de aplicación.

Saludos.

[Usuario887]

Existe una forma determinista de experimientar esto, y es programando y depurando con un capturador de paquetes de red ya sea TCPDump o Wireshark.

Voy a probar TCPDump.

Un paquete de red se compone en una serie de tramas.

Con "serie de tramas" te refieres a la pila de niveles de la red que existe en una transmicion, ¿No?. Es decir, a que, por ejemplo, segun el hecho de que existe dentro del campo de datos de TCP la trama HTTP, ¿Existen dos tramas en cuestion: la de TCP y la de HTTP?

Cuando recibes un paquete vía Socket estás recibiendo un paquete TCP o UDP. Dentro de esté en el campo de datos está el paquete HTTP embebido.

Creo que a eso te refieres con esto...

requeriría que en el campo de datos del paquete TCP esté el paquete HTTP, que el servidor extraiga el paquete HTTP y finalmente como este contiene otro paquete TCP lo enviaría al destino. Así que sí que se podría.

Claro, pero ¿Como podria siquiera existir una conexion HTTP sin una conexion TCP? en ese caso habrian dos conexiones TCP: la que sostiene la conexion HTTP en si y la que se "tunelea" por el mismo protocolo, ¿No?

Lo que quiero que quede claro es que tu PC recibe unas tramas y te muestra el paquete TCP/UDP si tu socket maneja paquetes TCP o UDP(datagramas) y en el campo de datos vendrían los paquetes de la capa de aplicación.

Eso ahora lo entiendo, gracias.

Saludos.



¿Conoces PuTTY? ¿Se podria usar de alguna forma para probar estos conceptos?

[MinusFour]

https://es.wikipedia.org/wiki/T%C3%BAnel_(inform%C3%A1tica)

¿A que se refiere exactamente con 'encapsular un protocolo'? ¿Como puede encapsularse un protocolo sobre otro? Lo unico que se me viene a la mente es un cast de estructuras de C 

Saludos...

Un proxy es un representante. Tu interactúas con el representante y el representante interactúa por ti con otros servicios. Tu router por ejemplo podría considerarse un proxy porque representa a todos los dispositivos en la red. Es el encargado de recibir información fuera de tu red y distribuirlos a los miembros de tu red.

Un túnel es simplemente una estructura para conectar dos puntos. Así que las conexiones de red fácilmente pueden ser consideradas como un túnel. Yo entiendo un túnel de red como un túnel dentro de la red. Podrías decir que es un túnel dentro de otro túnel. Es replicar una conexión dentro de una conexión.

Para comunicarte con el proxy (tu representante) podrías decir que usas un túnel. Por ejemplo, para comunicarte con una VPN (también considerados proxy) se necesita usualmente un túnel de red.

Son términos muy genéricos a decir verdad y por lo general se entiende solo una parte de lo que realmente significan.