Is it possible to combine multiple internet connections into one? There are many misconceptions and myths surrounding this topic; even experienced network engineers often do not know that it is possible. In most cases, the combination of links is mistakenly referred to as load balancing at the NAT level or failover. However, true aggregation allows to establish a single TCP connection across all internet connections simultaneously, for instance, for a video stream so that if any of the internet connections fail, the broadcast does not get interrupted.
There are expensive commercial solutions for video streaming, but such devices cost a lot of thousand dollars. This article describes the setup of the free, open package OpenMPTCPRouter and addresses popular myths about channel aggregation.
Myths about channel aggregation
There are many consumer routers that support the Multi-WAN feature. Sometimes manufacturers refer to it as channel aggregation, which is not entirely accurate. Many network professionals believe that aside from and aggregation at the L2 level, there is no other form of channel combining. I often hear from people working in telecoms that this is generally impossible. So, let's try to clarify some popular myths.
IP-level load balancing
This is the most accessible and popular method for utilizing multiple internet connections simultaneously. For simplicity, let’s imagine you have three internet service providers, each providing you with a real IP address from their network. All these providers are connected to a router that supports the Multi-WAN feature. This could be OpenWRT with the mwan3 package, MikroTik, Ubiquiti, or any other consumer router, as this option is now not uncommon.
To simulate the situation, let’s assume the providers have given us the following addresses:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN3 — 33.33.33.33
That is, by connecting to a remote server example.com Via elke provider zal de externe server drie onafhankelijke source IP's van de klant zien. Load balancing maakt het mogelijk om de belasting over de kanalen te verdelen en ze allemaal tegelijkertijd te gebruiken. Voor de eenvoud stellen we ons voor dat we de belasting gelijkmatig over alle kanalen verdelen. Uiteindelijk, wanneer de klant een website opent met bijvoorbeeld drie afbeeldingen, wordt elke afbeelding via een aparte provider geladen. Aan de websitezijde ziet dit eruit als verbindingen vanuit drie verschillende IP's.
Bij load balancing op verbindingsniveau gaat elke TCP-verbinding via een afzonderlijke provider.
Dit soort load balancing brengt vaak problemen met zich mee voor gebruikers. Veel websites koppelen namelijk strikter cookies en tokens aan het IP-adres van de klant, en als dit plotseling verandert, wordt het verzoek afgewezen of wordt de klant uitgelogd op de site. Dit gebeurt vaak in systemen voor internetbankieren en op andere sites met strikte regels voor gebruikerssessies. Hier is een eenvoudig voorbeeld: muziekbestanden op VK.com zijn alleen toegankelijk met een geldige sessiesleutel, die aan het IP is gekoppeld, en klanten die deze load balancing gebruiken kunnen vaak geen audio afspelen omdat het verzoek niet via de juiste provider is gestuurd waar de sessie aan is gekoppeld.
Bij het downloaden van torrents voegt load balancing op verbindingsniveau de bandbreedte van alle kanalen samen.
Dit soort load balancing maakt het mogelijk om de snelheid van de internetverbinding te combineren bij het gebruik van meerdere verbindingen. Bijvoorbeeld, als elke van de drie providers een snelheid van 100 Megabit heeft, dan krijgen we bij het downloaden van torrents 300 Megabit. Dit komt omdat torrents veel verbindingen openen die verdeeld worden over alle providers en uiteindelijk het volledige kanaal benutten.
Het is belangrijk te begrijpen dat één enkele TCP-verbinding altijd via één provider zal lopen. Dit betekent dat als we een groot bestand via HTTP downloaden, deze verbinding via een van de providers zal verlopen, en als de verbinding met deze provider wegvalt, zal de download ook falen.
Eén verbinding zal altijd slechts één internetkanaal gebruiken.
Dit geldt ook voor video-uitzendingen. Als je streamingvideo uitzendt op een platform zoals Twitch, zal IP-verbinding balancering geen bijzondere voordelen bieden, omdat de videostream binnen één IP-verbinding wordt uitgezonden. In dit geval, als de WAN-provider problemen met de verbinding ondervindt, zoals pakketverlies of een vertraging in de snelheid, dan kun je niet onmiddellijk overstappen naar een andere provider. De uitzending zal moeten worden gestopt en opnieuw verbonden.
Echte kanaalsomming
Echte kanaalsomming maakt het mogelijk om één verbinding naar bijvoorbeeld Twitch via alle providers te lopen, zodat als een van de providers uitvalt, de verbinding niet verbroken wordt. Dit is een verrassend complexe taak die nog steeds geen optimale oplossing heeft. Veel mensen weten zelfs niet dat dit mogelijk is!
Volgens de eerdere illustraties herinneren we ons dat de server van Twitch alleen een videostream van één source IP-adres kan accepteren, wat betekent dat dit altijd constant moet zijn, ongeacht welke providers zijn uitgevallen en welke nog werken. Om dit te bereiken, hebben we een samenvattende server nodig die al onze verbindingen beëindigt en ze tot één verbindt.
De samenvattende server aggregeert alle kanalen in één tunnel. Alle verbindingen komen vanaf het adres van de samenvattende server.
In zo'n schema worden alle providers gebruikt, en het uitschakelen van een van hen zal geen onderbreking van de verbinding met de Twitch-server veroorzaken. Het is in wezen een speciale VPN-tunnel die meerdere internetverbindingen onder de motorkap heeft. De hoofdtaak van zo'n schema is om de best mogelijke verbinding te verkrijgen. Als er problemen zijn bij een van de providers, zoals pakketverlies of verhoogde vertragingen, zou dit geen invloed moeten hebben op de kwaliteit van de verbinding, omdat de belasting automatisch zal worden verdeeld over andere, kwalitatief betere verbindingen die beschikbaar zijn.
Commerciële oplossingen
Dit probleem houdt al lang verband met degenen die live evenementen uitzenden en geen toegang hebben tot een goede internetverbinding. Voor deze situaties zijn er verschillende commerciële oplossingen, bijvoorbeeld, het bedrijf Teradek maakt zulke enorme routers waarin stapels USB-modems kunnen worden geplaatst:
Router voor videotransmissie met functie voor kanaalsummatie
Dergelijke apparaten hebben meestal de mogelijkheid om videosignalen via HDMI of SDI te verpakken. Bij de router wordt een abonnement op de kanaalsummatiedienst geleverd, evenals op de verwerking van de videostream, de transcodering ervan en de verdere retransmissie. De prijs van dergelijke apparaten begint bij $2000 met een set modems, plus een apart abonnement op de dienst.
Soms lijkt het behoorlijk intimiderend:
OpenMPTCPRouter instellen
Protocol (MultiPath TCP) is bedacht om de mogelijkheid te bieden om tegelijkertijd via meerdere kanalen te verbinden. Bijvoorbeeld, het en kan tegelijkertijd verbinding maken met een externe server via WiFi en via het mobiele netwerk. Het is belangrijk te begrijpen dat dit geen twee aparte TCP-verbindingen zijn, maar één verbinding die onmiddellijk via twee kanalen is opgezet. Om dit te laten functioneren, moet de externe server ook MPTCP ondersteunen.
is een open-source project van een software-router waarmee je daadwerkelijk kanalen kunt samensmelten. De auteurs beweren dat het project in de alpha-fase verkeert, maar het is al gebruiksklaar. Het bestaat uit twee delen - een sammensmeltende server die op het internet staat en een router waarop meerdere internetproviders en de klantapparaten zoals computers en telefoons zijn aangesloten. Een Raspberry Pi, enkele WiFi-routers of een gewone computer kunnen dienen als klantrouter. Er zijn kant-en-klare builds voor verschillende platforms, wat zeer handig is.
Werking van OpenMPTCPRouter
Instellen van de sammensmeltende server
De sammensmeltende server bevindt zich op het internet en beëindigt de verbindingen van alle kanalen van de klantrouter in één verbinding. Het IP-adres van deze server is het externe adres wanneer je via OpenMPTCPRouter het internet op gaat.
Voor deze taak zullen we een VPS-server op Debian 10 gebruiken.
Vereisten voor de sammensmeltende server:
- MPTCP werkt niet op OpenVZ-virtualisatie
- Er moet de mogelijkheid zijn om een eigen Linux-kernel te installeren.
De server wordt opgezet door één commando uit te voeren. Het script installeert de kernel met ondersteuning voor mptcp en alle noodzakelijke pakketten. Installatiescripts voor Ubuntu en Debian zijn beschikbaar.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Resultaat van een succesvolle serverinstallatie.
We save the passwords, as we'll need them to configure the client router, and then reboot. It's important to note that after installation, SSH will be accessible on port 65222. After rebooting, we need to ensure that we're booting with the new kernel.
uname -a
Linux test-server.local 4.19.67-mptcp
We see the label mptcp next to the version number, meaning the kernel has been installed correctly.
Configuration of the client router
Op ready-made builds are available for some platforms, such as Raspberry Pi, Banana Pi, Lynksys routers, and virtual machines.
This part of openmptcprouter is based on OpenWRT, using LuCI as the interface, familiar to anyone who has dealt with OpenWRT. The distribution weighs about 50MB!
As a test setup, I will use a Raspberry Pi and several USB modems from different operators: MTS and MegaFon. I believe no explanation is needed on how to write the image to an SD card.
Initially, the Ethernet port on the Raspberry Pi is set up as lan with a static IP address. 192.168.100.1. To avoid dealing with wires on the table, I connected the Raspberry Pi to a WiFi access point and set a static address on the computer's WiFi adapter. 192.168.100.2. The default DHCP server is not enabled, so static addresses need to be used.
Now we can access the web interface.
Upon first login, the system will ask for the root password, which will also be used for SSH access.
In the LAN settings, you can set the desired subnet and enable the DHCP server.
I use modems identified as USB Ethernet interfaces with an additional DHCP server, so this required the installation of . The procedure is identical to setting up modems in regular OpenWRT, so I will not cover it here.
Next, we need to configure the WAN interfaces. Initially, two virtual interfaces WAN1 and WAN2 are created in the system. They need to be assigned a physical device, in my case, the names of the USB modem interfaces.
To avoid confusion with interface names, I recommend checking the dmesg messages after connecting via SSH.
Since my modems themselves act as routers and have a DHCP server, I had to change the settings of their internal network ranges and disable the DHCP server, because initially, both modems issue addresses from the same network, causing a conflict.
OpenMPTCPRouter vereist dat de WAN-interface-adressen statisch zijn, dus we bedenken subnets voor de modems en configureren deze in het menu system → openmptcprouter → interface settings. Hier moeten we ook het IP-adres en de server sleutel opgeven, verkregen tijdens de installatie van de samengevoegde server.
In het geval van een succesvolle configuratie zou de statuspagina er ongeveer zo uit moeten zien. Het is duidelijk dat de router contact heeft kunnen maken met de samengevoegde server en beide kanalen normaal functioneren.
Standaard wordt de modus shadowsocks + mptcp gebruikt. Dit is een proxy die al het verkeer omhult. Aanvankelijk is het ingesteld om alleen TCP te verwerken, maar UDP kan ook worden ingeschakeld.
Als er geen fouten op de statuspagina staan, kan de configuratie als voltooid worden beschouwd.
Bij sommige providers kan het voorkomen dat de mptcp-vlag onderweg wordt verwijderd, wat leidt tot een fout:
In dit geval kan een andere werkmodus zonder MPTCP worden gebruikt, meer hierover .
Conclusie
Het OpenMPTCPRouter-project is zeer interessant en belangrijk, omdat dit waarschijnlijk de enige open-source oplossing is voor het probleem van kanaalsamensmelting. Alles andere is ofwel volledig gesloten en proprietary, of gewoon aparte modules, waarvan de gemiddelde gebruiker het moeilijk heeft om mee om te gaan. Op dit moment is het project nog vrij ruw, met uitermate beperkte documentatie; veel dingen zijn gewoon niet beschreven. Maar het werkt desondanks. Ik hoop dat het zich verder ontwikkelt, zodat we huishoudelijke routers krijgen die out of the box goed in staat zijn om kanalen samen te voegen.
Volg onze ontwikkelaar op Instagram
Bron: habr.com
