És possible combinar diversos canals d'Internet en un? Hi ha moltes idees errònies i mites sobre aquest tema; fins i tot els enginyers de xarxa experimentats sovint no saben que això és possible. En la majoria dels casos, l'agregació d'enllaços s'anomena erròniament equilibri a nivell de NAT o failover. Però la suma real ho permet llançar una única connexió TCP simultàniament a tots els canals d'Internet, per exemple, la difusió de vídeo de manera que si s'interromp algun dels canals d'Internet, l'emissió no s'interrompi.
Hi ha solucions comercials cares per a les emissions de vídeo, però aquests dispositius costen molts kilobucks. L'article descriu com configurar el paquet OpenMPTCPRuter gratuït i de codi obert i aborda els mites populars sobre la suma de canals.
Mites sobre la suma de canals
Hi ha molts encaminadors domèstics que admeten la funció Multi-WAN. De vegades, els fabricants anomenen aquesta suma de canals, cosa que no és del tot cert. Molts networkers creuen que a més i suma al nivell L2, no existeix cap altra agregació de canals. Sovint he sentit que això és generalment impossible de la gent que treballa en telecomunicacions. Per tant, intentem entendre els mites populars.
Equilibri a nivell de connexió IP
Aquesta és la manera més assequible i popular d'utilitzar diversos canals d'Internet alhora. Per simplificar, imaginem que teniu tres proveïdors d'Internet, cadascun us ofereix una adreça IP real de la seva xarxa. Tots aquests proveïdors estan connectats a un encaminador que admet la funció Multi-WAN. Això podria ser OpenWRT amb el paquet mwan3, mikrotik, ubiquiti o qualsevol altre encaminador domèstic, ja que aquesta opció ja no és estranya.
Per simular la situació, imaginem que els proveïdors ens van donar les següents adreces:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
És a dir, connectar-se a un servidor remot example.com A través de cadascun dels proveïdors, el servidor remot veurà tres clients IP d'origen independents. L'equilibri us permet dividir la càrrega entre canals i utilitzar-los simultàniament. Per simplificar, imaginem que dividim la càrrega per igual entre tots els canals. Com a resultat, quan un client obre un lloc amb tres imatges, baixa cada imatge a través d'un proveïdor independent. Al costat del lloc, sembla connexions de tres IP diferents.
Quan s'equilibra a nivell de connexió, cada connexió TCP passa per un proveïdor independent.
Aquest mode d'equilibri sovint causa problemes als usuaris. Per exemple, molts llocs uneixen estrictament galetes i testimonis a l'adreça IP del client i, si canvia de sobte, la sol·licitud es rebutja o el client es tanca la sessió del lloc. Això es reprodueix sovint en sistemes bancàries de clients i altres llocs amb regles de sessió d'usuari estrictes. Aquí teniu un exemple il·lustratiu senzill: els fitxers de música a VK.com només estan disponibles amb una clau de sessió vàlida, que està lligada a una IP, i els clients que utilitzen aquest equilibri sovint no reprodueixen àudio perquè la sol·licitud no va passar pel proveïdor al qual la sessió està empatada.
Quan es descarreguen torrents, l'equilibri del nivell de connexió suma l'ample de banda de tots els canals
Aquest equilibri us permet obtenir la suma de la velocitat del canal d'Internet quan feu servir múltiples connexions. Per exemple, si cadascun dels tres proveïdors té una velocitat de 100 megabits, en descarregar torrents obtindrem 300 megabits. Perquè un torrent obre moltes connexions, que es distribueixen entre tots els proveïdors i, finalment, utilitzen tot el canal.
És important entendre que una única connexió TCP sempre passarà per un sol proveïdor. És a dir, si descarreguem un fitxer gran mitjançant HTTP, aquesta connexió es farà a través d'un dels proveïdors, i si la connexió amb aquest proveïdor es trenca, la descàrrega també es trencarà.
Una connexió sempre utilitzarà un sol canal d'Internet
Això també és cert per a les emissions de vídeo. Si esteu emetent vídeo en streaming a algun tipus de Twitch condicional, l'equilibri a nivell de connexions IP no proporcionarà cap benefici particular, ja que el flux de vídeo s'emetrà dins d'una connexió IP. En aquest cas, si el proveïdor WAN 3 comença a tenir problemes amb la comunicació, com ara la pèrdua de paquets o la velocitat reduïda, no podreu canviar a un altre proveïdor a l'instant. L'emissió s'haurà d'aturar i tornar a connectar.
Veritable suma de canals
La suma del canal real permet executar una connexió a un Twitch condicional a través de tots els proveïdors alhora de manera que si algun dels proveïdors es trenca, la connexió no s'interromprà. Aquest és un problema sorprenentment difícil que encara no té una solució òptima. Molta gent ni tan sols sap que això és possible!
A partir de les il·lustracions anteriors, recordem que el servidor de Twitch condicional pot rebre un flux de vídeo de nosaltres només des d'una adreça IP d'origen, el que significa que sempre ha de ser constant per a nosaltres, independentment de quins proveïdors han caigut i quins estan funcionant. Per aconseguir-ho, necessitem un servidor de suma que finalitzi totes les nostres connexions i les combini en una sola.
El servidor de suma agrega tots els canals en un túnel. Totes les connexions provenen de l'adreça del servidor de suma
En aquest esquema, s'utilitzen tots els proveïdors i la desactivació de qualsevol d'ells no provocarà una pèrdua de comunicació amb el servidor de Twitch. Essencialment, es tracta d'un túnel VPN especial, sota el capó del qual hi ha diversos canals d'Internet alhora. La tasca principal d'aquest esquema és obtenir el canal de comunicació de la màxima qualitat. Si un dels proveïdors comença a tenir problemes, pèrdua de paquets, augment de retards, això no hauria d'afectar de cap manera la qualitat de la comunicació, ja que la càrrega es distribuirà automàticament per altres canals millors disponibles.
Solucions comercials
Aquest problema fa temps que preocupa els que transmeten esdeveniments en directe i no tenen accés a Internet d'alta qualitat. Per a aquestes tasques, hi ha diverses solucions comercials, per exemple, l'empresa Teradek fabrica encaminadors tan monstruosos en els quals s'insereixen paquets de mòdems USB:
Encaminador per a emissions de vídeo amb funció de suma de canals
Aquests dispositius solen tenir una capacitat integrada per capturar senyals de vídeo mitjançant HDMI o SDI. Juntament amb l'encaminador, es ven una subscripció al servei de suma de canals, a més de processar el flux de vídeo, transcodificar-lo i transmetre-lo més endavant. El preu d'aquests dispositius comença a partir de 2 dòlars amb un conjunt de mòdems, més una subscripció independent al servei.
De vegades sembla bastant espantós:
Configuració d'OpenMPTCPRuter
Protocol (MultiPath TCP) es va inventar per poder connectar-se a través de diversos canals alhora. Per exemple, la seva i es pot connectar simultàniament a un servidor remot mitjançant WiFi i mitjançant una xarxa mòbil. És important entendre que no es tracta de dues connexions TCP separades, sinó d'una connexió establerta a través de dos canals alhora. Perquè això funcioni, el servidor remot també ha de suportar MPTCP.
és un projecte d'encaminador de programari de codi obert que permet un veritable resum del canal. Els autors afirmen que el projecte es troba en estat de versió alfa, però que ja es pot utilitzar. Consta de dues parts: un servidor de suma, que es troba a Internet i un encaminador, al qual estan connectats diversos proveïdors d'Internet i els propis dispositius client: ordinadors, telèfons. L'encaminador personalitzat pot ser un Raspberry Pi, alguns encaminadors WiFi o un ordinador normal. Hi ha muntatges ja fets per a diverses plataformes, la qual cosa és molt convenient.
Com funciona OpenMPTCPRuter
Configuració d'un servidor de resum
El servidor de suma es troba a Internet i finalitza les connexions de tots els canals de l'encaminador client en un sol. L'adreça IP d'aquest servidor serà l'adreça externa en accedir a Internet mitjançant OpenMPTCPRuter.
Per a aquesta tasca farem servir un servidor VPS Debian 10.
Requisits per al servidor de suma:
- MPTCP no funciona amb la virtualització OpenVZ
- Hauria de ser possible instal·lar el vostre propi nucli Linux
El servidor es desplega executant una sola ordre. L'script instal·larà un nucli amb suport mptcp i tots els paquets necessaris. Hi ha scripts d'instal·lació disponibles per a Ubuntu и Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
El resultat d'una instal·lació correcta del servidor.
Desem les contrasenyes, les necessitarem per configurar l'encaminador del client, i reiniciem. És important tenir en compte que després de la instal·lació, SSH estarà disponible al port 65222. Després de reiniciar, ens hem d'assegurar que hem arrencat amb el nou nucli
uname -a
Linux test-server.local 4.19.67-mptcp
Veiem la inscripció mptcp al costat del número de versió, el que significa que el nucli s'ha instal·lat correctament.
Configuració d'un encaminador client
En Hi ha versions preparades per a algunes plataformes, com ara Raspberry Pi, Banana Pi, encaminadors Lynksys i màquines virtuals.
Aquesta part d'openmptcprouter es basa en OpenWRT, utilitzant LuCI com a interfície, familiar per a qualsevol que hagi trobat OpenWRT. La distribució pesa uns 50 MB!
Com a banc de proves, utilitzaré un Raspberry Pi i diversos mòdems USB amb diferents operadors: MTS i Megafon. No crec que hagi de dir-vos com escriure una imatge a una targeta SD.
Inicialment, el port Ethernet del Raspberry Pi es configura com a LAN amb una adreça IP estàtica 192.168.100.1. Per evitar jugar amb cables a l'escriptori, vaig connectar el Raspberry Pi a un punt d'accés WiFi i vaig configurar l'adaptador WiFi de l'ordinador en una adreça estàtica. 192.168.100.2. El servidor DHCP no està habilitat de manera predeterminada, de manera que heu d'utilitzar adreces estàtiques.
Ara podeu iniciar sessió a la interfície web
Quan inicieu sessió per primera vegada, el sistema us demanarà que establiu una contrasenya d'arrel; SSH estarà disponible amb la mateixa contrasenya.
A la configuració de la LAN, podeu establir la subxarxa desitjada i habilitar el servidor DHCP.
Utilitzo mòdems que es defineixen com a interfícies USB Ethernet amb un servidor DHCP independent, de manera que això requereix instal·lació . El procediment és idèntic a la configuració de mòdems a l'OpenWRT normal, així que no ho tractaré aquí.
A continuació, heu de configurar les interfícies WAN. Inicialment, el sistema va crear dues interfícies virtuals WAN1 i WAN2. Cal assignar-los un dispositiu físic, en el meu cas aquests són els noms de les interfícies de mòdem USB.
Per evitar confusions amb els noms de les interfícies, us recomano veure els missatges dmesg mentre us connecteu mitjançant SSH.
Com que els meus mòdems actuen com a encaminadors i ells mateixos tenen un servidor DHCP, vaig haver de canviar la configuració dels seus rangs de xarxa interns i desactivar el servidor DHCP, perquè inicialment tots dos mòdems emeten adreces des de la mateixa xarxa, i això provoca un conflicte.
L'OpenMPTCPRuter requereix que les adreces de la interfície WAN siguin estàtiques, de manera que proposem subxarxes per als mòdems i les configurem al sistema → openmptcprouter → menú de configuració de la interfície. Aquí heu d'especificar l'adreça IP i la clau del servidor obtingudes durant la instal·lació del servidor sumador.
Si la configuració és correcta, hauria d'aparèixer una imatge similar a la pàgina d'estat. Es pot veure que l'encaminador ha pogut arribar al servidor de suma i ambdós canals funcionen amb normalitat.
El mode predeterminat és shadowsocks + mptcp. Aquest és un servidor intermediari que inclou totes les connexions dins de si mateix. Inicialment està configurat per processar només TCP, però també es pot activar UDP.
Si no hi ha errors a la pàgina d'estat, la configuració es pot considerar completa.
Amb alguns proveïdors, es pot produir una situació quan la bandera mptcp es talla al llarg del camí de trànsit, aleshores apareixerà el següent error:
En aquest cas, podeu utilitzar un mode de funcionament diferent, sense utilitzar MPTCP, més informació sobre això .
Conclusió
El projecte OpenMPTCPRuter és molt interessant i important, ja que potser és l'única solució integral oberta al problema de la suma de canals. Tota la resta és ben tancada i propietari, o simplement mòduls separats que una persona normal no pot entendre. En l'actual fase de desenvolupament, el projecte encara és bastant cru, la documentació és extremadament pobre, moltes coses simplement no es descriuen. Però al mateix temps encara funciona. Espero que continuï desenvolupant-se i obtindrem encaminadors domèstics que siguin capaços de combinar correctament els canals de la caixa.
Segueix el nostre desenvolupador a Instagram
Font: www.habr.com
