¿Se pueden combinar múltiples canales de internet en uno solo? Hay muchos malentendidos y mitos en torno a este tema, incluso ingenieros de redes experimentados a menudo no saben que esto es posible. En la mayoría de los casos, la combinación de canales se confunde erróneamente con la balanceo a nivel de NAT o failover. Pero la verdadera agregación permite establecer una única conexión TCP que funcione a través de todos los canales de internet, por ejemplo, en una transmisión de video, de modo que si uno de los canales de internet falla, la emisión no se interrumpa.
Existen soluciones comerciales costosas para transmisiones de video, pero esos dispositivos pueden costar miles de dólares. Este artículo describe la configuración de un paquete gratuito y abierto llamado OpenMPTCPRouter, desmitificando los mitos populares sobre la agregación de canales.
Mitos sobre la agregación de canales
Hay muchos routers domésticos que admiten la función Multi-WAN. A veces, los fabricantes llaman a esto agregación de canales, lo cual no es del todo exacto. Muchos en el campo técnico creen que además de y la agregación a nivel L2, no existe ninguna otra forma de combinar canales. A menudo he escuchado de personas que trabajan en telecomunicaciones que eso es completamente imposible. Así que intentemos aclarar algunos de los mitos populares.
Balanceo a nivel de conexiones IP
Esta es la forma más accesible y popular de utilizar varios canales de internet al mismo tiempo. Para simplificar, imaginemos que tienes tres proveedores de internet, cada uno te asigna una dirección IP real de su red. Todos estos proveedores están conectados a un router que admite la función Multi-WAN. Esto puede ser OpenWRT con el paquete mwan3, mikrotik, ubiquiti o cualquier otro router doméstico, ya que actualmente esta opción no es rara.
Para simular la situación, imaginemos que los proveedores nos han otorgado estas direcciones:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN3 — 33.33.33.33
Es decir, al conectarse a un servidor remoto example.com A través de cada proveedor, el servidor remoto verá tres direcciones IP de origen independientes del cliente. La balanceo permite dividir la carga entre los canales y utilizar los tres simultáneamente. Para simplificar, imaginemos que estamos dividiendo la carga entre todos los canales de manera equitativa. Como resultado, cuando el cliente abre un sitio web que tiene, digamos, tres imágenes, carga cada imagen a través de un proveedor diferente. Desde el lado del sitio, esto se ve como conexiones desde tres IP diferentes.
En el balanceo a nivel de conexiones, cada conexión TCP pasa a través de un proveedor diferente.
Este modo de balanceo a menudo presenta problemas para los usuarios. Por ejemplo, muchos sitios atan estrictamente las cookies y los tokens a la dirección IP del cliente, y si esta cambia repentinamente, la solicitud es rechazada o el cliente es desconectado del sitio. Esto se reproduce frecuentemente en sistemas bancarios en línea y en otros sitios con estrictas reglas de sesiones de usuario. Aquí hay un ejemplo sencillo: los archivos musicales en VK.com están disponibles solo con una clave de sesión válida que está vinculada a una IP, y los clientes que utilizan este balanceo a menudo no pueden reproducir audio, ya que la solicitud no se envió a través del proveedor al que está vinculada la sesión.
Al descargar torrents, el balanceo a nivel de conexiones suma la capacidad de todos los canales.
Este balanceo permite obtener una suma de la velocidad del canal de Internet al utilizar múltiples conexiones. Por ejemplo, si cada uno de los tres proveedores tiene una velocidad de 100 Megabits, al descargar torrents obtendremos 300 Megabits. Esto se debe a que el torrent abre múltiples conexiones que se distribuyen entre todos los proveedores y, en última instancia, utilizan todo el canal.
Es importante entender que una única conexión TCP siempre pasará solo a través de un proveedor. Es decir, si estamos descargando un archivo grande a través de HTTP, esta conexión se realizará a través de uno de los proveedores, y si la conexión con ese proveedor se interrumpe, la descarga también fallará.
Una conexión siempre usará solo un canal de Internet.
Esto también se aplica a las transmisiones de video. Si transmites video en vivo en alguna plataforma como Twitch, la equilibración a nivel de conexiones IP no ofrecerá ningún beneficio especial, ya que la transmisión de video se hará a través de una única conexión IP. En este caso, si el proveedor de WAN 3 comienza a tener problemas de conexión, como pérdidas de paquetes o reducción de velocidad, no podrás cambiar inmediatamente a otro proveedor. Tendrás que detener la transmisión y reconectarte de nuevo.
Sumatoria de canales real
La sumatoria de canales real permite utilizar una sola conexión a Twitch a través de todos los proveedores de tal forma que, si cualquiera de los proveedores falla, la conexión no se interrumpa. Esta es una tarea sorprendentemente compleja que aún no tiene solución óptima. Muchos ni siquiera saben que es posible.
Como recordamos de las ilustraciones anteriores, un servidor de Twitch solo puede aceptar nuestra transmisión de video desde una única dirección IP de origen, por lo que debe ser siempre constante, independientemente de cuáles proveedores hayan fallado y cuáles estén funcionando. Para lograr esto, necesitaremos un servidor sumador que termine todas nuestras conexiones y las combine en una.
El servidor sumador agrega todos los canales en un solo túnel. Todas las conexiones se realizan desde la dirección del servidor sumador.
En este esquema se utilizan todos los proveedores, y la desconexión de cualquiera de ellos no provocará la pérdida de conexión con el servidor de Twitch. Esencialmente, es un túnel VPN especial, bajo el cual hay varios canales de Internet. La principal tarea de este esquema es obtener la máxima calidad de conexión. Si uno de los proveedores enfrenta problemas, pérdidas de paquetes o aumentos en la latencia, esto no debería afectar la calidad de la conexión, ya que la carga se redistribuirá automáticamente a otros canales más confiables que estén disponibles.
Soluciones comerciales
Este problema ha preocupado durante mucho tiempo a quienes realizan transmisiones en vivo de eventos y no tienen acceso a una buena conexión a Internet. Para tales tareas existen varias soluciones comerciales, por ejemplo, la empresa Teradek fabrica enrutadores monstruosos en los que se insertan paquetes de módems USB:
Router para transmisiones de video con función de agregación de canales
En estos dispositivos, generalmente, hay una función integrada para capturar señales de video a través de HDMI o SDI. Junto con el router se vende una suscripción al servicio de agregación de canales, así como el procesamiento del flujo de video, su recodificación y retransmisión. El precio de estos dispositivos comienza desde 2k$ con un paquete de módems, más la suscripción al servicio por separado.
A veces, esto parece bastante intimidante:
Configuramos OpenMPTCPRouter
Protocolo (MultiPath TCP) fue diseñado para permitir conexiones a través de múltiples canales simultáneamente. Por ejemplo, su y puede conectarse simultáneamente a un servidor remoto a través de WiFi y mediante la red celular. Es importante entender que no son dos conexiones TCP separadas, sino una única conexión establecida a través de dos canales. Para que esto funcione, el servidor remoto también debe soportar MPTCP.
es un proyecto de software de router abierto que realmente permite agregar canales. Los autores afirman que el proyecto está en estado alfa, pero ya se puede utilizar. Consiste en dos partes: un servidor agregador que se aloja en internet y un router al que se conectan varios proveedores de internet y los propios dispositivos cliente: computadoras, teléfonos. Como router de usuario se puede utilizar una Raspberry Pi, algunos routers WiFi o una computadora común. Hay construcciones listas para diversas plataformas, lo que es muy conveniente.
Principio de funcionamiento de OpenMPTCPRouter
Configuración del servidor agregador
El servidor agregador se encuentra en internet y termina las conexiones de todos los canales del router cliente en una sola. La dirección IP de este servidor será la dirección externa al salir a internet a través de OpenMPTCPRouter.
Para esta tarea, utilizaremos un servidor VPS con Debian 10.
Requisitos para el servidor agregador:
- MPTCP no funciona en virtualización OpenVZ
- Debe ser posible instalar su propio núcleo de Linux
El servidor se despliega ejecutando un solo comando. El script instalará el núcleo con soporte para mptcp y todos los paquetes necesarios. Hay scripts de instalación disponibles para Ubuntu y Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Resultado de la instalación exitosa del servidor.
Guardamos las contraseñas, que necesitaremos para configurar el enrutador del cliente, y reiniciamos. Es importante tener en cuenta que después de la instalación, SSH estará disponible en el puerto 65222. Después del reinicio, debemos asegurarnos de que hemos arrancado con el nuevo núcleo.
uname -a
Linux test-server.local 4.19.67-mptcp
Vemos junto al número de versión la etiqueta mptcp, lo que significa que el núcleo se ha instalado correctamente.
Configuración del enrutador del cliente
En hay compilaciones listas disponibles para algunas plataformas, como Raspberry Pi, Banana Pi, enrutadores Lynksys y máquinas virtuales.
Esta parte de openmptcprouter se basa en OpenWRT, utilizando LuCI como interfaz, familiar para aquellos que han trabajado con OpenWRT. ¡La distribución pesa alrededor de 50 MB!
Como banco de pruebas, estaré utilizando una Raspberry Pi y varios módems USB de diferentes operadores: MTS y MegaFon. No creo que necesite explicar cómo grabar la imagen en una tarjeta SD.
Inicialmente, el puerto Ethernet en Raspberry Pi está configurado como LAN con una dirección IP estática. 192.168.100.1. Para no enredarme con los cables en la mesa, conecté la Raspberry Pi a un punto de acceso WiFi y asigné una dirección estática en el adaptador WiFi de la computadora. 192.168.100.2. El servidor DHCP por defecto no está habilitado, por lo que necesitamos usar direcciones estáticas.
Ahora podemos ingresar a la interfaz web.
En la primera entrada, el sistema pedirá establecer la contraseña root, con la misma contraseña se podrá acceder a SSH.
En la configuración de LAN, se puede establecer la subred deseada y habilitar el servidor DHCP.
Uso módems que se identifican como interfaces USB Ethernet con un servidor DHCP separado, por lo que esto requirió la instalación . El procedimiento es idéntico a la configuración de módems en un OpenWRT normal, por lo que no lo trataré aquí.
A continuación, necesitamos configurar las interfaces WAN. Inicialmente, el sistema crea dos interfaces virtuales WAN1 y WAN2. Debemos asignarles un dispositivo físico, en mi caso, los nombres de las interfaces de los módems USB.
Para no confundirme con los nombres de las interfaces, recomiendo consultar los mensajes de dmesg, conectándome por SSH.
Dado que mis módems actúan como enrutadores y tienen su propio servidor DHCP, tuve que cambiar la configuración de sus rangos de red internos y deshabilitar el servidor DHCP, ya que inicialmente ambos módems asignan direcciones de una misma red, lo que causa conflictos.
OpenMPTCPRouter requiere que las direcciones de las interfaces WAN sean estáticas, por lo que asignamos subredes a los módems y configuramos en el menú system → openmptcprouter → interface settings. Aquí también es necesario indicar la dirección IP y la clave del servidor, obtenida en la etapa de instalación del servidor agregador.
Si la configuración es exitosa, en la página de estado debería aparecer una imagen similar. Se puede ver que el enrutador ha podido conectarse al servidor agregador y ambos canales están funcionando correctamente.
Por defecto, se utiliza el modo shadowsocks + mptcp. Esto es un proxy que envuelve todas las conexiones. Originalmente, está configurado para manejar solo TCP, pero se puede habilitar también UDP.
Si en la página de estado no hay errores, se puede considerar que la configuración ha finalizado.
Con algunos proveedores, puede surgir la situación en la que la bandera mptcp se corta en el camino del tráfico, en cuyo caso se mostrará el siguiente error:
En este caso, se puede utilizar otro modo de operación, sin usar MPTCP; más detalles sobre esto. .
Conclusión
El proyecto OpenMPTCPRouter es muy interesante e importante, ya que es, quizás, la única solución integral de código abierto para el problema de la agregación de canales. Todo lo demás es o bien completamente cerrado y propietario, o simplemente módulos separados con los que una persona común no puede lidiar. En esta etapa de desarrollo, el proyecto aún es bastante inmaduro, con documentación muy escasa y muchas cosas simplemente no están descritas. Pero aun así, funciona. Espero que continúe desarrollándose y que podamos conseguir enrutadores domésticos que puedan combinar canales adecuadamente desde la caja.
Síguenos en Instagram
Fuente: habr.com
