Lehetséges több internetes csatorna egybekapcsolása? Nagyon sok tévhit és mítosz kering a témával kapcsolatban, gyakran még a tapasztalt hálózatmérnökök sem tudják, hogy ez lehetséges. A legtöbb esetben a hivatkozás-összesítést tévesen NAT-kiegyenlítésnek vagy feladatátvételnek nevezik. De a valódi összegzés megengedi egyetlen TCP-kapcsolatot futtathat egyszerre az összes internetes csatornán, például videó adás, hogy ha valamelyik internetes csatorna megszakad, az adás ne szakadjon meg.
Léteznek drága kereskedelmi megoldások a videó sugárzásra, de az ilyen eszközök sok kilóba kerülnek. A cikk leírja az ingyenes, nyílt OpenMPTCPRuter csomag konfigurációját, és foglalkozik a csatornaösszegzésről szóló népszerű mítoszokkal.
Mítoszok a csatornaösszegzésről
Számos otthoni útválasztó támogatja a Multi-WAN funkciót. Néha a gyártók ezt a csatornát összegzésnek nevezik, ami nem teljesen igaz. Sok hálózatépítő úgy véli, hogy amellett és összegzés az L2 rétegben, nincs más csatorna-összesítés. Gyakran hallottam, hogy ez általában lehetetlen a távközlésben dolgozóktól. Ezért próbáljuk meg megérteni a népszerű mítoszokat.
Kiegyensúlyozás az IP kapcsolatok szintjén
Ez a legolcsóbb és legnépszerűbb módja több internetes csatorna egyidejű használatának. Az egyszerűség kedvéért képzeljük el, hogy három internetszolgáltatója van, amelyek mindegyike valódi IP-címet ad a hálózatából. Mindezek a szolgáltatók olyan útválasztóhoz csatlakoznak, amely támogatja a Multi-WAN funkciót. Ez lehet OpenWRT mwan3 csomaggal, mikrotik, ubiquiti, vagy bármilyen más háztartási router, hiszen ez a lehetőség ma már nem ritka.
A helyzet szimulálásához képzeljük el, hogy a szolgáltatók a következő címeket adták meg nekünk:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Vagyis távoli szerverhez való csatlakozás example.com az egyes szolgáltatókon keresztül a távoli kiszolgáló az ügyfél három független forrás-ip-jét fogja látni. A kiegyensúlyozás lehetővé teszi a terhelés felosztását a csatornák között, és mindhárom csatornát egyidejűleg használja. Az egyszerűség kedvéért képzeljük el, hogy a terhelést egyenlően osztjuk el az összes csatorna között. Ennek eredményeként, ha egy ügyfél feltételesen megnyit egy webhelyet három képpel, akkor mindegyik képet külön szolgáltatón keresztül tölti le. A webhely oldalán három különböző IP-ről származó kapcsolatoknak tűnik.
A kapcsolat szintjén történő egyensúlyozáskor minden TCP-kapcsolat külön szolgáltatón keresztül megy keresztül.
Ez az egyensúlyozási mód gyakran okoz problémákat a felhasználóknak. Például sok webhely cookie-kat és tokeneket köt be a kliens IP-címére, és ha ez hirtelen megváltozik, a kérést eldobják, vagy az ügyfél kijelentkezik az oldalról. Ezt gyakran reprodukálják az ügyfél-bank rendszerek és más webhelyek szigorú felhasználói munkamenet-szabályokkal. Íme egy egyszerű szemléltető példa: a VK.com-on található zenefájlok csak érvényes, IP-hez kötött munkamenetkulccsal érhetők el, és az ilyen kiegyenlítést használó kliensek gyakran nem játszanak le hangot, mert a kérés nem azon a szolgáltatón keresztül ment át, amelyhez a munkamenet kötött.
Torrentek letöltésekor a kapcsolat szintjén történő egyensúlyozás az összes csatorna sávszélességét összegzi
Az ilyen kiegyenlítés lehetővé teszi az internetcsatorna sebességének összegzését több kapcsolat használatakor. Például, ha mindhárom szolgáltató 100 megabites sebességgel rendelkezik, akkor torrentek letöltésekor 300 megabites sebességet kapunk. Mivel a torrent sok olyan kapcsolatot nyit meg, amelyek az összes szolgáltató között megoszlanak, és végül a teljes csatornát kihasználják.
Fontos megérteni, hogy egyetlen TCP-kapcsolat mindig csak egy szolgáltatón keresztül megy keresztül. Vagyis ha egy nagy fájlt töltünk le HTTP-n keresztül, akkor ez a kapcsolat az egyik szolgáltatón keresztül jön létre, és ha megszakad a kapcsolat ezzel a szolgáltatóval, akkor a letöltés is megszakad.
Egy kapcsolat mindig csak egy internetes csatornát használ
Ez igaz a videoközvetítésekre is. Ha valamilyen feltételes Twitch-en streaming videót sugároz, akkor az IP-kapcsolatok szintjén történő egyensúlyozás nem jár különösebb előnnyel, mivel a videofolyam egy IP-kapcsolaton belül kerül sugárzásra. Ebben az esetben, ha a WAN 3 szolgáltatónál kommunikációs problémák lépnek fel, például csomagvesztés vagy lassulás, akkor nem tud azonnal másik szolgáltatóra váltani. Az adást le kell állítani, és újra csatlakoztatni kell.
Igazi csatornaösszegzés
A csatornák valós összegzése lehetővé teszi, hogy a feltételes Twitch-hez egy csatlakozást indítsunk el az összes szolgáltatón keresztül egyszerre úgy, hogy ha valamelyik szolgáltató megszakad, a kapcsolat nem szakad meg. Ez egy meglepően nehéz probléma, amelyre még mindig nincs optimális megoldás. Sokan nem is tudják, hogy ez lehetséges!
Az előző illusztrációkból emlékszünk rá, hogy a feltételes Twitch szerver csak egy forrás IP-címről tud tőlünk videó streamet fogadni, ami azt jelenti, hogy nálunk mindig állandónak kell lennie, függetlenül attól, hogy melyik szolgáltató esett le és melyik működik. Ennek eléréséhez szükségünk van egy összegző szerverre, amely megszakítja az összes kapcsolatunkat és egyesíti őket.
Az összegző szerver az összes csatornát egy alagútba összesíti. Minden kapcsolat az összegző szerver címéről származik
Ez a séma az összes szolgáltatót használja, és ezek egyikének letiltása nem okoz kommunikációt a Twitch szerverrel. Valójában ez egy speciális VPN-alagút, amelynek motorháztetője alatt egyszerre több internetes csatorna található. Egy ilyen rendszer fő feladata a legjobb minőségű kommunikációs csatorna megszerzése. Ha valamelyik szolgáltatónál kezdõdnek a problémák, csomagvesztés, késések növekedése, akkor ez semmilyen módon nem befolyásolhatja a kommunikáció minõségét, hiszen a terhelés automatikusan eloszlik a többi, rendelkezésre álló jobb csatornán.
Kereskedelmi megoldások
Ez a probléma régóta foglalkoztatja azokat, akik élőben közvetítik az eseményeket, és nem férnek hozzá a jó minőségű internethez. Az ilyen feladatokra számos kereskedelmi megoldás létezik, például a Teradek olyan szörnyű útválasztókat készít, amelyekbe USB-modemcsomagokat helyeznek be:
Broadcast video router csatorna összegző funkcióval
Az ilyen eszközök általában képesek HDMI-n vagy SDI-n keresztül videót rögzíteni. A routerrel együtt eladják a csatornaösszesítő szolgáltatásra való előfizetést, valamint a videó stream feldolgozását, átkódolását és továbbadását. Az ilyen eszközök ára 2 ezer dollártól kezdődik modemkészlettel, valamint külön előfizetéssel a szolgáltatásra.
Néha elég ijesztőnek tűnik:
Az OpenMPTCPRuter beállítása
Jegyzőkönyv A (MultiPath TCP) arra lett kitalálva, hogy egyszerre több csatornán tudjon kapcsolódni. Például az övét és egyidejűleg csatlakozhat egy távoli szerverhez WiFi-n és mobilhálózaton keresztül. Fontos megérteni, hogy ez nem két különálló TCP kapcsolat, hanem egy 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ú szoftveres útválasztó projekt, amely lehetővé teszi a csatornák valódi összegzését. A szerzők azt állítják, hogy a projekt alfa verzió státuszban van, de már használható. Két részből áll - egy összegző szerverből, amely az interneten található, és egy útválasztóból, amelyhez több internetszolgáltató és maga az ügyféleszköz is csatlakozik: számítógépek, telefonok. Egyéni router lehet Raspberry Pi, néhány WiFi router vagy hagyományos számítógép. Különféle platformokhoz vannak kész szerelvények, ami nagyon kényelmes.
Hogyan működik az OpenMPTCPRuter
Összefoglaló szerver beállítása
Az összegző szerver az interneten található, és a kliens útválasztó összes csatornájáról a kapcsolatokat bontja le. Ennek a szervernek az IP-címe lesz a külső cím, amikor az OpenMPTCPRuteren keresztül csatlakozik az internethez.
Ehhez a feladathoz egy VPS szervert fogunk használni a Debian 10 rendszeren.
Követelmények az összegző szerverrel szemben:
- Az MPTCP nem működik az OpenVZ virtualizáción
- Lehetővé kell tenni a saját Linux kernel telepítését
A kiszolgáló telepítése egyetlen parancs végrehajtásával történik. A szkript telepít egy kernelt mptcp támogatással és az összes szükséges csomagot. A telepítő szkriptek elérhetők Ubuntu és Debian számára.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Sikeres szervertelepítés eredménye.
Mentjük a jelszavakat, szükségünk lesz rájuk a kliens útválasztó konfigurálásához és az újraindításhoz. Fontos szem előtt tartani, hogy a telepítés után az SSH elérhető lesz a 65222-es porton. Újraindítás után meg kell győződnünk arról, hogy az új kernellel indulunk.
uname -a
Linux test-server.local 4.19.67-mptcp
A verziószám mellett az mptcp feliratot látjuk, ami azt jelenti, hogy a kernel megfelelően lett telepítve.
Kliens útválasztó beállítása
tovább Kész buildek állnak rendelkezésre egyes platformokhoz, például Raspberry Pi, Banana Pi, Lynksys útválasztókhoz és virtuális gépekhez.
Az openmptcprouter ezen része az OpenWRT-n alapul, és LuCI-t használ interfészként, mindenki számára ismerős, aki valaha találkozott az OpenWRT-vel. Az elosztókészlet súlya körülbelül 50 Mb!
Tesztpadként Raspberry Pi-t és több USB modemet fogok használni különböző kezelőkkel: MTS és Megafon. Azt hiszem, nem kell elmondanom, hogyan írhat képet SD-kártyára.
Kezdetben a Raspberry Pi Ethernet-portja LAN-ként van konfigurálva, statikus IP-címmel. 192.168.100.1. Hogy ne vacakoljak az asztalon lévő vezetékekkel, csatlakoztattam a Raspberry Pi-t egy WiFi hozzáférési ponthoz, és statikus címet állítottam be a számítógép WiFi adapterén. 192.168.100.2. A DHCP szerver alapértelmezés szerint nincs engedélyezve, ezért statikus címeket kell használni.
Most léphet a webes felületre
Első bejelentkezéskor a rendszer kérni fogja a root jelszó megadását, az SSH ugyanazzal a jelszóval lesz elérhető.
A LAN beállításokban beállíthatja a kívánt alhálózatot és engedélyezheti a DHCP szervert.
USB ethernet interfészként definiált modemeket használok külön DHCP szerverrel, ezért ez telepítést igényelt . Az eljárás megegyezik a modemek normál OpenWRT-ben történő beállításával, ezért itt nem térek ki rá.
Ezután konfigurálnia kell a WAN interfészt. Kezdetben két virtuális interfész WAN1 és WAN2 került kialakításra a rendszerben. Fizikai eszközt kell hozzárendelniük, esetemben ezek az USB modem interfészek nevei.
Annak érdekében, hogy ne keveredjen össze az interfésznevek között, azt tanácsolom, hogy nézze meg a dmesg üzeneteket, miközben SSH-n keresztül csatlakozik.
Mivel a modemeim maguk is routerekként működnek, és nekik is van DHCP szerverük, a belső hálózati tartományaik beállításait kellett módosítanom és a DHCP szervert le kellett tiltanom, mert kezdetben mindkét modem ugyanarról a hálózatról ad ki címeket, és ez ütközést okoz.
Az OpenMPTCPRuter megköveteli, hogy a WAN interfész címei statikusak legyenek, ezért alhálózatokat találunk ki a modemekhez, és a rendszer → openmptcprouter → interfész beállítások menüben konfiguráljuk azokat. Itt kell megadni az összegző szerver telepítése során kapott IP-címet és szerverkulcsot.
Sikeres beállítás esetén hasonló képnek kell megjelennie az állapotoldalon. Látható, hogy a router el tudta érni az összegző szervert és mindkét csatorna megfelelően működik.
Az alapértelmezett mód a shadowsocks + mptcp. Ez egy proxy, amely minden kapcsolatot magában foglal. Kezdetben csak a TCP feldolgozására van beállítva, de az UDP is engedélyezhető.
Ha nincs hiba az állapotoldalon, a beállítás befejezettnek tekinthető.
Egyes szolgáltatóknál előfordulhat olyan helyzet, amikor az mptcp jelzőt csonkolják a forgalmi útvonalon, akkor ilyen hiba lesz:
Ebben az esetben más üzemmódot is használhat, MPTCP használata nélkül, erről bővebben .
Következtetés
Az OpenMPTCPRuter projekt nagyon érdekes és fontos, hiszen talán ez az egyetlen nyitott komplex megoldás a csatornaösszegzés problémájára. Minden más vagy szorosan zárt és saját tulajdonú, vagy csak különálló modulok, amelyekkel egy hétköznapi ember nem tud foglalkozni. A fejlesztés jelenlegi szakaszában a projekt még elég nyers, rendkívül gyenge dokumentáció, sok minden egyszerűen nincs leírva. De ugyanakkor még mindig működik. Bízom benne, hogy tovább fog fejlődni, és olyan háztartási routereket kapunk, amelyek már a dobozból kiveszik majd a normál csatornákat kombinálni.
Kövesd fejlesztőnket az Instagramon
Forrás: will.com