Je možné sloučit několik internetových kanálů do jednoho? Okolo této tématu se točí spousta nedorozumění a mýtů, dokonce i zkušení síťoví inženýři často nevědí, že je to možné. Většinou se sloučením kanálů mylně nazývá vyvažování na úrovni NAT nebo failover. Skutečné sčítání však umožňuje posílat jedno jediné TCP připojení současně přes všechny internetové kanály, například videopřenos, tak aby při přerušení jakéhokoliv z internetových kanálů vysílání nepřestalo.
Existují drahé komerční řešení pro videopřenosy, ale taková zařízení stojí mnoho tisíc dolarů. V článku se popisuje nastavení bezplatného, otevřeného balíčku OpenMPTCPRouter a vyvracejí se oblíbené mýty o sčítání kanálů.
Mýty o sčítání kanálů
Existuje mnoho běžných routerů, které podporují funkci Multi-WAN. Někdy ji výrobci nazývají sčítáním kanálů, což není zcela přesné. Mnoho síťových administrátorů věří, že kromě a sčítání na úrovni L2 žádné jiné sloučení kanálů neexistuje. Často jsem slyšel, že je to vůbec nemožné od lidí, kteří pracují v telekomunikacích. Proto se pokusíme objasnit populární mýty.
Vyvažování na úrovni IP připojení
To je nejdostupnější a nejoblíbenější způsob, jak využívat několik internetových kanálů najednou. Pro jednoduchost si představme, že máte tři internetové poskytovatele, každý vám vydává skutečnou IP adresu ze své sítě. Všichni tito poskytovatelé jsou připojeni k routeru, který podporuje funkci Multi-WAN. Může to být OpenWRT s balíčkem mwan3, mikrotik, ubiquiti nebo jakýkoliv jiný běžný router, protože dnes už taková možnost není vzácností.
Pro modelování situace si představme, že nám poskytovatelé vydali takové adresy:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN3 — 33.33.33.33
To znamená, že se připojujeme k vzdálenému serveru example.com Přes každého z poskytovatelů bude vzdálený server vidět tři nezávislé IP adresy klienta. Zatížení umožňuje rozdělit zátěž mezi kanály a využívat je všechny tři současně. Pro jednoduchost si představme, že rozdělujeme zátěž mezi všechny kanály rovnoměrně. Když klient otevře web, na kterém jsou hypoteticky tři obrázky, každý obrázek se načítá přes jiného poskytovatele. Na straně webu to vypadá jako připojení ze tří různých IP adres.
Při zátěžovém vyrovnávání na úrovni připojení, každé TCP připojení prochází přes samostatného poskytovatele.
Tento způsob zátěžového vyrovnávání často přináší problémy pro uživatele. Například mnoho webů pevně spojuje cookie a tokeny s IP adresou klienta, a pokud se ta náhle změní, požadavek je odmítnut nebo se klient odhlásí ze stránky. To se často reprodukuje v systémech online bankovnictví a na dalších stránkách s přísnými pravidly uživatelských relací. Tady je jednoduchý názorný příklad: hudební soubory na VK.com jsou dostupné pouze s platným klíčem relace, který je spojen s IP adresou, a u klientů, kteří používají takové zátěžové vyrovnávání, se často nedaří přehrávat audio, protože požadavek odešel přes jiného poskytovatele, ke kterému je relace přiřazena.
Při stahování torrentů zátěžové vyrovnávání na úrovni připojení součtu přenosovou kapacitu všech kanálů.
Toto zátěžové vyrovnávání umožňuje součtovou rychlost internetového kanálu při použití mnoha připojení. Například, pokud má každý ze tří poskytovatelů rychlost 100 Megabitů, při stahování torrentů dostaneme 300 Megabitů. Protože torrent otevírá mnoho připojení, které se rozdělují mezi všechny poskytovatele a nakonec využívají celý kanál.
Je důležité rozumět, že jedno jediné TCP připojení vždy projde pouze přes jednoho poskytovatele. To znamená, že pokud stahujeme jeden velký soubor přes HTTP, toto připojení bude provedeno přes jednoho z poskytovatelů, a pokud spojení s tímto poskytovatelem selže, tak i stahování se přeruší.
Jedno připojení vždy využije pouze jeden internetový kanál.
To platí i pro video streaming. Pokud vysíláte streamované video na nějakém hypotetickém Twitchi, pak vyvážení na úrovni IP připojení nepřinese žádný zvláštní prospěch, jelikož videostream bude vysílán v rámci jednoho IP připojení. V tomto případě, pokud má WAN poskytovatel 3 problémy s komunikací, například ztrátu paketů nebo snížení rychlosti, nebudete se moci okamžitě přepnout na jiného poskytovatele. Vysílání budete muset zastavit a znovu se připojit.
Skutečné sumárování kanálů
Reálné sumárování kanálů umožňuje poslat jedno připojení na hypotetický Twitch přes všechny poskytovatele tak, že pokud nějaký z poskytovatelů selže, připojení se nepřeruší. To je překvapivě složitý úkol, který dosud nemá optimální řešení. Mnozí ani nevědí, že něco takového je možné!
Z předchozích ilustrací si pamatujeme, že hypotetický server Twitch může přijmout od nás videostream pouze z jedné source IP adresy, což znamená, že musí být vždy stálá, bez ohledu na to, kteří poskytovatelé selhali a kdo funguje. Abychom toho dosáhli, potřebujeme sumární server, který ukončí všechna naše připojení a sloučí je do jednoho.
Sumární server agreguje všechny kanály do jednoho tunelu. Veškerá připojení probíhají z adresy sumárního serveru.
V tomto schématu se používají všichni poskytovatelé a odpojení jakéhokoli z nich nezpůsobí přerušení spojení se serverem Twitch. V podstatě se jedná o speciální VPN tunel, pod kterým je několik internetových kanálů. Hlavním cílem takového schématu je dosáhnout co nejkvalitnějšího komunikačního kanálu. Pokud nastanou problémy u jednoho z poskytovatelů, ztráta paketů nebo zvýšení latence, nemělo by to mít žádný dopad na kvalitu spojení, jelikož zátěž se automaticky rozloží na jiné kvalitnější kanály, které jsou k dispozici.
Komereční řešení
Tento problém už dlouho trápí ty, kteří vedou živé přenosy událostí a nemají přístup k kvalitnímu internetu. Pro takové úkoly existuje několik komerčních řešení, například firma Teradek vyrábí takové monstrózní routery, do kterých se zasunují balíky USB modemů:
Router pro videostreaming s funkcí agregace kanálů
Taková zařízení obvykle obsahují možnost zachytit vide signál přes HDMI nebo SDI. Spolu s routerem se prodává předplatné na službu agregace kanálů, stejně jako zpracování video streamu, jeho překódování a další retransmise. Cena takových zařízení začíná od 2k$ s sadou modemů, k tomu se připočítává samostatné předplatné na službu.
Někdy to vypadá dost děsivě:
Nastavujeme OpenMPTCPRouter
Protokol (MultiPath TCP) byl vynalezen pro možnost připojit se najednou k několika kanálům. Například jeho a může se současně připojit k vzdálenému serveru přes WiFi a přes mobilní síť. Je důležité si uvědomit, že se nejedná o dvě samostatná TCP připojení, ale o jediné připojení, navázané najednou přes dva kanály. Aby to fungovalo, vzdálený server musí také podporovat MPTCP.
je otevřený projekt softwarového routeru, který umožňuje skutečně agregovat kanály. Autoři tvrdí, že projekt je ve stádiu alpha verze, ale již je možné ho používat. Skládá se ze dvou částí – agregujícího serveru, který je umístěn na internetu a routeru, ke kterému se připojuje několik internetových poskytovatelů a samotná klientská zařízení: počítače, telefony. Jako uživatelský router může sloužit Raspberry Pi, některé WiFi routery nebo běžný počítač. Existují hotové sestavy pro různé platformy, což je velmi pohodlné.
Princip fungování OpenMPTCPRouter
Nastavení agregujícího serveru
Agregující server se nachází na internetu a terminates connections from all channels of the client router into one. The IP address of this server will be the external address when going online via OpenMPTCPRouter.
Pro tuto úlohu budeme používat VPS server na Debian 10.
Požadavky na agregující server:
- MPTCP nefunguje na virtualizaci OpenVZ
- Musí být možnost instalace vlastního jádra Linux
Server se nasadí vykonáním jednoho příkazu. Skript nainstaluje jádro s podporou mptcp a všechny potřebné balíčky. Jsou k dispozici instalační skripty pro Ubuntu a Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Výsledek úspěšné instalace serveru.
Ukládáme hesla, budou potřeba pro konfiguraci klientského routeru, a restartujeme. Je důležité mít na paměti, že po instalaci bude SSH dostupné na portu 65222. Po restartu je potřeba se ujistit, že jsme se spustili s novým jádrem.
uname -a
Linux test-server.local 4.19.67-mptcp
Vedle čísla verze vidíme nápis mptcp, to znamená, že jádro bylo nainstalováno správně.
Nastavení klientského routeru
Na jsou k dispozici hotové sestavení pro některé platformy, například Raspberry Pi, Banana Pi, routery Lynksys a virtuální stroje.
Tato část openmptcprouter je založena na OpenWRT, jako rozhraní se používá LuCI, známé všem, kdo se kdy setkali s OpenWRT. Distribuce váží přibližně 50 MB!
Jako testovací platformu budu používat Raspberry Pi a několik USB modemů od různých operátorů: MTS a MegaFon. Jak zapsat obraz na SD kartu, myslím, že není třeba vysvětlovat.
Původně je Ethernet port v Raspberry Pi nastaven jako lan se statickou IP adresou. 192.168.100.1. Abych se nemusel zabývat kabely na stole, připojil jsem Raspberry Pi k WiFi hotspotu a nastavil na WiFi adaptéru počítače statickou adresu. 192.168.100.2. Výchozí DHCP server není povolen, proto je třeba používat statické adresy.
Nyní je možné přistoupit do webového rozhraní.
Při prvním přihlášení systém požádá o zadání hesla root, pod kterým bude dostupné také SSH.
V nastavení LAN lze nastavit požadovanou podsíť a povolit DHCP server.
Používám modemy, které se identifikují jako USB Ethernet rozhraní s odděleným DHCP serverem, takže to vyžadovalo instalaci . Postup je totožný s konfigurací modemů v běžném OpenWRT, takže to zde nebudu rozebírat.
Dále je potřeba nastavit WAN rozhraní. Původně jsou v systému vytvořena dva virtuální rozhraní WAN1 a WAN2. Je třeba jim přiřadit fyzické zařízení, v mém případě se jedná o názvy rozhraní USB modemů.
Abych se nezamotal v názvech rozhraní, doporučuji sledovat zprávy dmesg, pokud se připojíte přes SSH.
Jelikož moje modemy sama vystupují jako routery a mají vlastní DHCP server, musel jsem změnit nastavení jejich vnitřních rozsahů sítí a vypnout DHCP server, protože původně oba modemy poskytují adresy z jedné sítě, což způsobuje konflikt.
OpenMPTCPRouter vyžaduje, aby adresy WAN rozhraní byly statické, proto vytvoříme podsítě pro modemy a nastavíme je v menu system → openmptcprouter → interface settings. Zde je také potřeba uvést IP adresu a klíč serveru, který byl získán během instalace agregovaného serveru.
Pokud byla konfigurace úspěšná, na stránce stavu by se mělo objevit podobné zobrazení. Je jasné, že router se mohl spojit s agregovaným serverem a oba kanály fungují správně.
Ve výchozím nastavení se používá režim shadowsocks + mptcp. Jedná se o proxy, která obaluje všechna připojení. Původně je nastavena tak, aby zpracovávala pouze TCP, ale lze zapnout i UDP.
Pokud na stránce stavu nejsou žádné chyby, můžeme považovat konfiguraci za dokončenou.
U některých poskytovatelů může nastat situace, kdy je vlajka mptcp na cestě provozu odstraněna, pak se objeví takováto chybu:
V takovém případě lze použít jiný pracovní režim, bez použití MPTCP, více informací o tom .
Závěr
Projekt OpenMPTCPRouter je velmi zajímavý a důležitý, protože je to pravděpodobně jediné otevřené komplexní řešení problému agregace kanálů. Vše ostatní je buď zcela uzavřené a proprietární, nebo jen jednotlivé moduly, s kterými si běžný člověk nedokáže poradit. V současné fázi vývoje je projekt stále dost nezralý, má velmi chudou dokumentaci, mnoho věcí není jednoduše popsáno. Ale přesto stále funguje. Doufám, že se bude i nadále vyvíjet a dostaneme domácí routery, které budou schopny sloučit kanály z krabice.
Sledujte našeho vývojáře na Instagramu
Zdroj: habr.com
