En las redes informáticas , un protocolo de tunelización es un protocolo de comunicación que permite el movimiento de datos de una red a otra. Puede, por ejemplo, permitir que las comunicaciones de una red privada se envíen a través de una red pública (como Internet ), o que un protocolo de red se transmita a través de una red incompatible, a través de un proceso llamado encapsulamiento .
Debido a que la tunelización implica reempaquetar los datos de tráfico en un formato diferente, quizás con cifrado como estándar, puede ocultar la naturaleza del tráfico que pasa por un túnel.
El protocolo de tunelización funciona utilizando la parte de datos de un paquete (la carga útil ) para transportar los paquetes que realmente proporcionan el servicio. La tunelización utiliza un modelo de protocolo en capas, como los de la suite de protocolos OSI o TCP/IP , pero normalmente viola la estratificación cuando se utiliza la carga útil para transportar un servicio que normalmente no proporciona la red. Normalmente, el protocolo de entrega funciona a un nivel igual o superior en el modelo en capas que el protocolo de carga útil.
Un protocolo de tunelización puede, por ejemplo, permitir que un protocolo externo se ejecute en una red que no admite ese protocolo en particular, como ejecutar IPv6 en IPv4 .
Otro uso importante es proporcionar servicios que no son prácticos o seguros si se ofrecen utilizando solo los servicios de red subyacentes, como proporcionar una dirección de red corporativa a un usuario remoto cuya dirección de red física no es parte de la red corporativa.
Los usuarios también pueden utilizar la tunelización para "escabullirse" a través de un cortafuegos, utilizando un protocolo que el cortafuegos normalmente bloquearía, pero "envuelto" dentro de un protocolo que el cortafuegos no bloquea, como HTTP . Si la política del cortafuegos no excluye específicamente este tipo de "envoltura", este truco puede funcionar para eludir la política del cortafuegos prevista (o cualquier conjunto de políticas de cortafuegos interconectadas).
Otro método de tunelización basado en HTTP utiliza el método/comando HTTP CONNECT . Un cliente emite el comando HTTP CONNECT a un proxy HTTP. A continuación, el proxy establece una conexión TCP con un puerto de servidor en particular y retransmite datos entre ese puerto de servidor y la conexión del cliente. [1] Debido a que esto crea un agujero de seguridad, los proxies HTTP con capacidad CONNECT suelen restringir el acceso al método CONNECT. El proxy permite conexiones solo a puertos específicos, como 443 para HTTPS. [2]
Otros métodos de tunelización capaces de eludir los cortafuegos de red utilizan diferentes protocolos como DNS , [3] MQTT , [4] SMS . [5]
Como ejemplo de capa de red sobre capa de red, el encapsulamiento de enrutamiento genérico (GRE), un protocolo que se ejecuta sobre IP ( protocolo IP número 47), suele servir para transportar paquetes IP, con direcciones privadas RFC 1918, por Internet utilizando paquetes de entrega con direcciones IP públicas. En este caso, los protocolos de entrega y carga útil son los mismos, pero las direcciones de carga útil son incompatibles con las de la red de entrega.
También es posible establecer una conexión mediante la capa de enlace de datos. El protocolo de túnel de capa 2 (L2TP) permite la transmisión de tramas entre dos nodos. Un túnel no está cifrado por defecto: el protocolo TCP/IP elegido determina el nivel de seguridad.
SSH utiliza el puerto 22 para permitir el cifrado de datos de las cargas útiles que se transmiten a través de una conexión de red pública (como Internet), lo que proporciona la funcionalidad de VPN . IPsec tiene un modo de transporte de extremo a extremo, pero también puede funcionar en modo de tunelización a través de una puerta de enlace de seguridad confiable.
Para comprender una pila de protocolos particular impuesta por la tunelización, los ingenieros de redes deben comprender tanto los conjuntos de protocolos de carga útil como de entrega.
La tunelización de una carga útil que encapsula TCP (como PPP ) sobre una conexión basada en TCP (como el reenvío de puertos de SSH) se conoce como "TCP sobre TCP", y hacerlo puede inducir una pérdida drástica en el rendimiento de la transmisión, conocida como el problema de fusión de TCP [6] [7], por lo que el software de red privada virtual (VPN) puede utilizar en su lugar un protocolo más simple que TCP para la conexión del túnel. La fusión de TCP se produce cuando una conexión TCP se apila sobre otra. La capa subyacente puede detectar un problema e intentar compensarlo, y la capa superior sobrecompensa debido a eso, y esta sobrecompensación causa dichos retrasos y un rendimiento de transmisión degradado.
Un túnel Secure Shell (SSH) consiste en un túnel cifrado creado a través de una conexión de protocolo SSH . Los usuarios pueden configurar túneles SSH para transferir tráfico no cifrado a través de una red mediante un canal cifrado . Se trata de un enfoque basado en software para la seguridad de la red y el resultado es un cifrado transparente. [8]
Por ejemplo, las máquinas Microsoft Windows pueden compartir archivos mediante el protocolo Server Message Block (SMB), un protocolo no cifrado. Si se montara un sistema de archivos Microsoft Windows de forma remota a través de Internet, alguien que espiara la conexión podría ver los archivos transferidos. Para montar el sistema de archivos Windows de forma segura, se puede establecer un túnel SSH que dirija todo el tráfico SMB al servidor de archivos remoto a través de un canal cifrado. Aunque el protocolo SMB en sí no contiene cifrado, el canal SSH cifrado a través del cual viaja ofrece seguridad.
Una vez que se ha establecido una conexión SSH, el túnel comienza con SSH escuchando un puerto en el host remoto o local. Cualquier conexión a él se reenvía al host especificado. dirección y puerto de origen del host opuesto (remoto o local, como anteriormente).
El problema de la fusión de TCP no suele ser un problema cuando se utiliza el reenvío de puertos de OpenSSH, porque muchos casos de uso no implican la tunelización TCP sobre TCP; la fusión se evita porque el cliente OpenSSH procesa la conexión TCP local del lado del cliente para llegar a la carga útil real que se está enviando y luego envía esa carga útil directamente a través de la propia conexión TCP del túnel al lado del servidor, donde el servidor OpenSSH de manera similar "desenvuelve" la carga útil para "envolverla" nuevamente para enrutarla a su destino final. [9] Naturalmente, este envoltura y desenvoltura también ocurre en la dirección inversa del túnel bidireccional.
Los túneles SSH proporcionan un medio para eludir los cortafuegos que prohíben determinados servicios de Internet, siempre que un sitio permita conexiones salientes. Por ejemplo, una organización puede prohibir a un usuario acceder a páginas web de Internet (puerto 80) directamente sin pasar por el filtro proxy de la organización (que proporciona a la organización un medio para supervisar y controlar lo que el usuario ve a través de la web). Pero es posible que los usuarios no deseen que el filtro proxy de la organización supervise o bloquee su tráfico web. Si los usuarios pueden conectarse a un servidor SSH externo , pueden crear un túnel SSH para reenviar un puerto determinado de su máquina local al puerto 80 de un servidor web remoto. Para acceder al servidor web remoto, los usuarios apuntarían su navegador al puerto local en http://localhost/
Algunos clientes SSH admiten el reenvío dinámico de puertos , lo que permite al usuario crear un proxy SOCKS 4/5. En este caso, los usuarios pueden configurar sus aplicaciones para que utilicen su servidor proxy SOCKS local. Esto proporciona más flexibilidad que la creación de un túnel SSH a un único puerto, como se describió anteriormente. SOCKS puede liberar al usuario de las limitaciones de conectarse únicamente a un puerto y servidor remotos predefinidos. Si una aplicación no admite SOCKS, se puede utilizar un proxy para redirigir la aplicación al servidor proxy SOCKS local. Algunos proxys, como Proxycap, admiten SSH directamente, lo que evita la necesidad de un cliente SSH.
En versiones recientes de OpenSSH, incluso se permite crear túneles de capa 2 o capa 3 si ambos extremos tienen habilitadas dichas capacidades de tunelización. Esto crea interfaces virtuales tun(capa 3, predeterminadas) o tap(capa 2) en ambos extremos de la conexión. Esto permite utilizar la gestión y el enrutamiento de red normales y, cuando se utiliza en enrutadores, se puede tunelizar el tráfico de una subred completa. Un par de tapinterfaces virtuales funcionan como un cable Ethernet que conecta ambos extremos de la conexión y pueden unir puentes de kernel.
A lo largo de los años, la tunelización y la encapsulación de datos en general se han adoptado con frecuencia por motivos maliciosos, con el fin de comunicarse maliciosamente fuera de una red protegida.
En este contexto, los túneles conocidos involucran protocolos como HTTP , [10] SSH , [11] DNS , [12] [13] MQTT . [14]
El código de reenvío TCP también es bastante rápido. Solo para responder una pregunta de antemano, ssh desencapsula y vuelve a encapsular TCP, por lo que no tienes problemas clásicos de TCP sobre TCP.