Lehetséges több internetcsatorna egyesítése? E körül a téma körül számos félreértés és mítosz kering, még a tapasztalt hálózati mérnökök között is gyakori, hogy nem tudják, hogy ez lehetséges. A legtöbb esetben a csatornák egyesítését hibásan NAT szintű terheléselosztásnak vagy failover-nek nevezik. De az igazi összegzés lehetővé teszi egy egyetlen TCP-kapcsolaton keresztül az összes internetcsatorna egyidejű használatát, például videostreaming-et, úgy, hogy bármelyik internetcsatorna megszakadása esetén a közvetítés ne akadjon meg.
Léteznek drága kereskedelmi megoldások videostreaming számára, de ezek az eszközök sok ezer dollárba kerülnek. A cikk bemutatja a nyílt és ingyenes OpenMPTCPRouter csomag beállítását, és megvizsgálja a csatornaegyesítés körüli népszerű mítoszokat.
Mítoszok a csatornaegyesítésről
Sok háztartási router létezik, amely támogatja a Multi-WAN funkciót. Néha a gyártók ezeket csatornaegyesítésnek nevezik, ami nem pontosan igaz. Sokan a szakmában azt hiszik, hogy az LACP-n kívül Terheléselosztás IP-kapcsolatok szintjén
Ez a legelterjedtebb és legnépszerűbb módja annak, hogy egyszerre több internetcsatornát használjunk. Egyszerűsítésképpen tegyük fel, hogy három internet szolgáltatónk van, mindegyik valós IP-címet ad a saját hálózatából. Mindhárom szolgáltató csatlakozik egy Multi-WAN funkciót támogató routerhez. Ez lehet OpenWRT a mwan3 csomaggal, mikrotik, ubiquiti vagy bármely más háztartási router, hiszen ma már ez az opció nem ritka.
A helyzet modellezésére tegyük fel, hogy a szolgáltatók a következő címeket adták:
WAN1 — 11.11.11.11 WAN2 — 22.22.22.22 WAN3 — 33.33.33.33
Tehát, ha csatlakozunk egy távoli szerverhez
Azaz, csatlakozva egy távoli szerverhez example.com Minden szolgáltatón keresztül a távoli szerver három független kliens IP-t fog látni. A terheléskiegyenlítés lehetővé teszi, hogy megosszuk a terhelést a csatornák között, és ezeket egyszerre használjuk. Egyszerűség kedvéért képzeljük el, hogy a terhelést egyenlően osztjuk meg az összes csatorna között. Ennek eredményeként, amikor a kliens megnyit egy weboldalt, amely feltételezhetően három képet tartalmaz, minden egyes képet egy külön szolgáltatón keresztül tölt le. A weboldal oldalán ez úgy néz ki, mintha három különböző IP-címről csatlakoznának.
A kapcsolati szintű terheléskiegyenlítés esetén minden egyes TCP-kapcsolat egy külön szolgáltatón keresztül megy.
Ez a terheléskiegyenlítési mód gyakran problémákat okoz a felhasználók számára. Például sok weboldal szigorúan összekapcsolja a cookie-kat és a tokeneket a kliens IP-címével, és ha az hirtelen megváltozik, akkor a kérés elutasításra kerül, vagy a felhasználót kijelentkezteti az oldalról. Ez gyakran megfigyelhető a banki alkalmazásokban és más olyan webhelyeken, ahol szigorú felhasználói ülésszabályok vannak. Itt van egy egyszerű példa: a VK.com zenefájlai csak érvényes munkamenet kulcs mellett érhetők el, amely hozzárendelődik az IP-hez, és azoknál a klienseknél, akik ezt a terheléskiegyenlítést használják, gyakran nem játszódtak le a hanganyagok, mert a kérés nem a munkamenethez hozzárendelt szolgáltatón keresztül ment.
Torrentek letöltésekor a kapcsolati szintű terheléskiegyenlítés összeadja az összes csatorna sávszélességét.
Ez a terheléskiegyenlítés lehetővé teszi, hogy internetkapcsolat gyorsaságának összegyűjtését érjük el, ha több kapcsolaton keresztül használjuk. Például, ha mindhárom szolgáltató sebessége 100 megabit, akkor torrentek letöltésekor 300 megabit sebességet kapunk. Mivel a torrent sok kapcsolatot nyit, amelyek minden szolgáltató között oszlanak meg, végül teljes mértékben kihasználják a sávszélességet.
Fontos megérteni, hogy egyetlen TCP-kapcsolat mindig csak egy szolgáltatón keresztül megy. Tehát ha egy nagy fájlt töltünk le HTTP-n, akkor ez a kapcsolat egyik szolgáltatón keresztül fog létrejönni, és ha a kapcsolat megszakad ezzel a szolgáltatóval, akkor a letöltés is megszakad.
Egyetlen kapcsolat mindig csak egy internetcsatornát fog használni.
Ez igaz a videó közvetítésekre is. Ha élő videót sugárzol mondjuk a Twitch-re, akkor az IP-kapcsolatok szintjén végzett terheléselosztás nem nyújt különösebb előnyöket, hiszen a videóstream egyetlen IP-kapcsolaton belül kerül továbbításra. Ebben az esetben, ha a WAN szolgáltatónál problémák lépnek fel a kapcsolatban, például csomagvesztés vagy sebességcsökkenés, akkor nem tudsz azonnal átállni egy másik szolgáltatóra. A közvetítést le kell állítani, és újra csatlakozni kell.
Valódi csatornaszámítás
A valódi csatornaszámítás lehetővé teszi, hogy egy kapcsolaton keresztül az összes szolgáltatónkön keresztül kapcsolódjunk a Twitch-hez, így ha bármelyik szolgáltató hibát jelez, a kapcsolat nem szakad meg. Ez meglepően bonyolult feladat, amelyre eddig nem létezik optimális megoldás. Sokan nem is tudják, hogy ez lehetséges!
Az előző illusztrációkból emlékezhetünk, hogy a Twitch kiszolgáló csak egy source IP címről tud fogadni videóstreamet, tehát állandónak kell lennie, függetlenül attól, hogy mely szolgáltatók álltak le és melyek működnek. Ennek eléréséhez szükségünk lesz egy aggregáló szerverre, amely terminálja az összes kapcsolatunkat és egyesíti őket egybe.
Az aggregáló szerver összesíti az összes csatornát egy alagútba. Minden kapcsolat az aggregáló szerver címéről történik.
Ebben a rendszerben minden szolgáltató részt vesz, és bármelyikük kikapcsolása nem okoz megszakadást a Twitch szerverrel. Alapvetően ez egy különleges VPN-alagút, amely alatt egyszerre több internetcsatorna működik. Ennek a rendszernek a fő célja a lehető legjobb kapcsolati minőség biztosítása. Ha az egyik szolgáltatónál problémák merülnek fel, csomagvesztés, késleltetésnövekedés, akkor ez semmilyen módon nem tükröződik a kapcsolat minőségén, mivel a terhelés automatikusan átcsoportosul a más, jobb minőségű csatornákra, amelyek rendelkezésre állnak.
Kereskedelmi megoldások
Ez a probléma már régóta foglalkoztatja azokat, akik eseményeket közvetítenek, és nincsenek hozzáférésük jó minőségű internethez. Az ilyen feladatokhoz több kereskedelmi megoldás létezik, például a Teradek cég ilyen monstrózus routereket gyárt, amelyekbe csomó USB modem helyezhető:
Videók streaming router csatorna összegzési funkcióval
Ezekben az eszközökben általában van beépített lehetőség HDMI vagy SDI videójel rögzítésére. A routerhez a csatorna összegző szolgáltatás előfizetése is jár, valamint a videófolyam feldolgozása, újrakódolása és továbbítása. Az ilyen eszközök ára 2000 dollárról kezdődik modem készlettel, plusz külön előfizetés a szolgáltatásra.
Néha ez elég ijesztően néz ki:
OpenMPTCPRouter beállítása
Protokoll (MultiPath TCP) azt a lehetőséget kínálja, hogy egyszerre több csatornán kapcsolódjunk. Például, az és egyszerre tud WiFi-n és mobilhálózaton kapcsolódni egy távoli szerverhez. Fontos megérteni, hogy ez nem két külön TCP-kapcsolat, hanem egyetlen kapcsolat, amely egyszerre két csatornán jön létre. Ahhoz, hogy ez működjön, a távoli szervernek is támogatnia kell az MPTCP-t.
egy nyílt forráskódú szoftver router projekt, amely valóban lehetővé teszi a csatornák összegzését. A szerzők azt állítják, hogy a projekt alfa verzióban van, de már használható. Két részből áll – egy összegző szerverből, amely az interneten található, és egy routerből, amelyhez több internetszolgáltató és a kliens eszközök csatlakoznak: számítógépek, telefonok. Felhasználói routerként Raspberry Pi, néhány WiFi router vagy akár egy egyszerű számítógép is használható. Különböző platformokhoz vannak kész telepítések, ami nagyon kényelmes.
Az OpenMPTCPRouter működési elve
Összegző szerver beállítása
Az összegző szerver az interneten található, és minden csatornából érkező kapcsolódást egybe von. Ennek a szervernek az IP-címe lesz a külső cím, amikor az OpenMPTCPRouter-en keresztül csatlakozik az internetre.
Ehhez a feladathoz egy Debian 10 VPS szervert fogunk használni.
Az összegző szerver követelményei:
- Az MPTCP nem működik OpenVZ virtualizáción
- Lehetőség kell legyen saját Linux kernel telepítésére
A szerver egy parancs végrehajtásával felállítható. A szkript telepíti az MPTCP támogatású kernelt és a szükséges csomagokat. Telepítési szkriptek állnak rendelkezésre Ubuntu és Debian számára.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
A szerver sikeres telepítésének eredménye.
Tartsuk az jelszavakat, amelyek szükségesek lesznek a kliens router beállításához, majd újraindítunk. Fontos megjegyezni, hogy az SSH az 65222-es porton lesz elérhető a telepítés után. Az újraindítás után meg kell győződnünk arról, hogy az új kernel töltődött be.
uname -a
Linux test-server.local 4.19.67-mptcp
Látjuk, hogy a verziószám mellett megjelenik az mptcp felirat, ami azt jelenti, hogy a kernel helyesen települt.
Kliens router beállítása
Ezen kész gyűjtemények elérhetők egyes platformokhoz, például Raspberry Pi, Banana Pi, Lynksys routerekhez és virtuális gépekhez.
Ez a rész az openmptcprouterből az OpenWRT-n alapul, az interfész a LuCI, amely mindenki számára ismert, aki valaha is találkozott az OpenWRT-vel. A disztribúció körülbelül 50 MB méretű!
Tesztkörnyezetként Raspberry Pi-t és néhány USB modemet fogok használni különböző szolgáltatókkal: MTS és Megafon. Úgy gondolom, nem szükséges bemutatni, hogyan írjuk a képet SD-kártyára.
Kezdetben az Ethernet port a Raspberry Pi-n lan-ként van beállítva statikus IP-címmel. 192.168.100.1. Annak érdekében, hogy ne kelljen vezetékkel bajlódnom az asztalon, csatlakoztattam a Raspberry Pi-t egy WiFi hozáférési ponthoz, és statikus címet adtam a számítógép WiFi adapterének. 192.168.100.2. Az alapértelmezett DHCP-szerver ki van kapcsolva, így statikus címeket kell használni.
Most már beléphetünk a webes felületre.
Első belépéskor a rendszer kérni fogja a root jelszó megadását, ugyanezt a jelszót használhatjuk az SSH-hoz is.
A LAN beállításokban megadhatjuk a szükséges alhálózatot és engedélyezhetjük a DHCP-szervert.
Olyan modemeket használok, amelyek USB Ethernet interfészként ismerhetők fel, külön DHCP-szerverrel, ezért további csomagok telepítése szükséges. . A folyamat azonos a modemek beállításával a normál OpenWRT-ben, így ezt itt nem fogom részletezni.
Ezután be kell állítani a WAN interfészeket. Kezdetben a rendszer két virtuális WAN interfészt hoz létre, WAN1 és WAN2. Fizikai eszközöket kell hozzárendelniük, az én esetemben ezek az USB modemek interfészeinek nevei.
Hogy ne keveredjek az interfészek neveivel, javaslom, hogy nézze meg a dmesg üzeneteket, miután SSH-n keresztül csatlakozott.
Mivel a modemjeim maguk is routerként funkcionálnak, és saját DHCP-szerverük van, módosítanom kellett a belső hálózati tartományok beállításait, és ki kellett kapcsolnom a DHCP-szervert, mert kezdetben mindkét modem egy hálózatból osztotta ki az IP-címeket, ami ütközést okoz.
Az OpenMPTCPRouter megköveteli, hogy a WAN interfészek címei statikusak legyenek, ezért kitalálunk alhálózatokat a modemeknek, és beállítjuk a menu rendszer → openmptcprouter → interfész beállítások alatt. Itt meg kell adni az IP-címet és a szerver kulcsát, amelyet a gyűjtő szerver telepítésekor kaptunk.
Sikeres beállítás esetén a státusz oldalon hasonló képet kell látnunk. Látható, hogy a router kapcsolatot tudott létesíteni a gyűjtő szerverrel, és mindkét csatorna normálisan működik.
Alapértelmezésben a shadowsocks + mptcp üzemmód használatos. Ez egy olyan proxy, amely beburkolja az összes kapcsolatot. Eredetileg csak a TCP kezelésére van beállítva, de lehetőség van az UDP engedélyezésére is.
Ha a státusz oldalon nincs hiba, a beállítást befejezettnek tekinthetjük.
Néhány szolgáltatóval előfordulhat, hogy a forgalom útján az mptcp jel levágódik, akkor a következő hiba lép fel:
Ebben az esetben használhatunk egy másik üzemmódot, MPTCP használata nélkül, erről részletesebben .
Zárás
Az OpenMPTCPRouter projekt nagyon érdekes és fontos, mivel ez talán az egyetlen nyílt, komplex megoldás a csatornák összevonásának problémájára. Minden más vagy teljesen zárt és saját, vagy egyszerűen csak különálló modulok, amikkel egy átlagos ember számára nehéz megbirkózni. A projekt jelenlegi fejlődési szakaszában még elég nyers, a dokumentáció rendkívül szegényes, sok dolog egyszerűen nincs leírva. De mégis működik. Remélem, hogy továbbra is fejlődni fog, és kapunk olyan otthoni routereket, amelyek már dobozból is képesek normálisan összevonni a csatornákat.
Kövess minket a fejlesztőnk Instagramján
Forrás: habr.com
