Ĉu eblas kombini plurajn interretajn kanalojn en unu? Estas multaj miskomprenoj kaj mitoj ĉirkaŭ ĉi tiu temo, eĉ spertaj retaj inĝenieroj ofte ne scias, ke tio eblas. Plejofte, ligo-agregado estas erare referita kiel NAT-balancado aŭ malsukceso. Sed reala sumo permesas ruli unu ununuran TCP-konekton samtempe tra ĉiuj interretaj kanaloj, ekzemple, videoelsendo tiel ke se iu el la Interretaj kanaloj estas interrompita, la elsendo ne estos interrompita.
Estas multekostaj komercaj solvoj por videoelsendado, sed tiaj aparatoj kostas multajn kilobukojn. La artikolo priskribas la agordon de la senpaga, malfermita pakaĵo OpenMPTCPRuter, kaj traktas popularajn mitojn pri kanalsumado.
Mitoj pri sumado de kanaloj
Estas multaj hejmaj enkursigiloj, kiuj subtenas la funkcion Multi-WAN. Kelkfoje fabrikantoj nomas ĉi tiun kanalan sumon, kio ne estas tute vera. Multaj retuloj kredas tion krom kaj sumigo ĉe la L2-tavolo, neniu alia kanalagregacio ekzistas. Mi ofte aŭdis, ke ĉi tio ĝenerale neeblas de homoj, kiuj laboras en telekomunikadoj. Tial ni provu kompreni popularajn mitojn.
Ekvilibro je la nivelo de IP-konektoj
Ĉi tio estas la plej malmultekosta kaj populara maniero uzi plurajn interretan kanalojn samtempe. Por simpleco, ni imagu, ke vi havas tri ISP-ojn, ĉiu donante al vi realan IP-adreson de sia reto. Ĉiuj ĉi tiuj provizantoj estas konektitaj al enkursigilo kun subteno por la funkcio Multi-WAN. Ĉi tio povas esti OpenWRT kun la pakaĵo mwan3, mikrotik, ubiquiti aŭ ajna alia hejma enkursigilo, ĉar nun ĉi tiu opcio ne plu estas malofta.
Por simuli la situacion, imagu, ke la provizantoj donis al ni la sekvajn adresojn:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Tio estas, konekti al fora servilo example.com tra ĉiu el la provizantoj, la fora servilo vidos tri sendependaj fonto ip de la kliento. Ekvilibro permesas vin dividi la ŝarĝon tra kanaloj kaj uzi ilin ĉiujn tri samtempe. Por simpleco, ni imagu, ke ni dividas la ŝarĝon inter ĉiuj kanaloj egale. Kiel rezulto, kiam kliento malfermas retejon kun tri bildoj, li elŝutas ĉiun bildon per aparta provizanto. Ĉe la retejo, ĝi aspektas kiel konektoj de tri malsamaj IP-oj.
Dum ekvilibro ĉe la konektnivelo, ĉiu TCP-konekto pasas tra aparta provizanto.
Ĉi tiu ekvilibra reĝimo ofte kaŭzas problemojn por uzantoj. Ekzemple, multaj retejoj fiksas kuketojn kaj ĵetonojn al la IP-adreso de la kliento, kaj se ĝi subite ŝanĝiĝas, la peto estas forigita aŭ la kliento elsalutas en la retejo. Ĉi tio ofte estas reproduktita en klient-bankaj sistemoj kaj aliaj retejoj kun striktaj uzantkunsiaj reguloj. Jen simpla ilustra ekzemplo: muzikdosieroj en VK.com haveblas nur kun valida seanca ŝlosilo, kiu estas ligita al IP, kaj klientoj uzantaj tian ekvilibron ofte ne ludas audio, ĉar la peto ne trapasis la provizanton al kiu la ekvilibro. kunsido estas ligita.
Dum elŝuto de torentoj, ekvilibro ĉe la konektnivelo sumigas la bendolarĝon de ĉiuj kanaloj
Tia ekvilibro permesas vin akiri la sumon de la rapideco de la interreta kanalo kiam vi uzas plurajn konektojn. Ekzemple, se ĉiu el la tri provizantoj havas rapidon de 100 megabitoj, tiam elŝutante torentojn ni ricevos 300 megabitojn. Ĉar la torento malfermas multajn konektojn, kiuj estas distribuitaj inter ĉiuj provizantoj kaj eventuale utiligas la tutan kanalon.
Gravas kompreni, ke unu sola TCP-konekto ĉiam trairos nur unu provizanton. Tio estas, se ni elŝutas unu grandan dosieron per HTTP, tiam ĉi tiu konekto estos farita per unu el la provizantoj, kaj se la konekto kun ĉi tiu provizanto rompas, tiam la elŝuto ankaŭ rompiĝos.
Unu konekto ĉiam uzos nur unu Interretan kanalon
Ĉi tio validas ankaŭ por videoelsendoj. Se vi elsendas fluan videon sur iu kondiĉa Twitch, tiam ekvilibro ĉe la nivelo de IP-konektoj ne donos apartan avantaĝon, ĉar la videofluo estos elsendo ene de unu IP-konekto. En ĉi tiu kazo, se la provizanto de WAN 3 komencas havi problemojn pri komunikado, kiel paka perdo aŭ malrapidiĝo, tiam vi ne povos tuj ŝanĝi al alia provizanto. La elsendo devos esti haltigita kaj rekonektita.
Vera kanalsumo
La vera sumo de kanaloj ebligas komenci unu konekton al la kondiĉa Twitch tra ĉiuj provizantoj samtempe tiel, ke se iu el la provizantoj rompas, la konekto ne estos interrompita. Ĉi tio estas surprize malfacila problemo, kiu ankoraŭ ne havas optimuman solvon. Multaj eĉ ne scias, ke tio eblas!
El la antaŭaj ilustraĵoj, ni memoras, ke la kondiĉa Twitch-servilo povas ricevi videofluon de ni de nur unu fonta IP-adreso, kio signifas, ke ĝi ĉiam devas esti konstanta ĉe ni, sendepende de kiuj provizantoj defalis kaj kiuj funkcias. Por atingi ĉi tion, ni bezonas suman servilon, kiu finos ĉiujn niajn ligojn kaj kunfandos ilin en unu.
La suma servilo kunigas ĉiujn kanalojn en unu tunelon. Ĉiuj konektoj originas de la adreso de la suma servilo
Ĉi tiu skemo uzas ĉiujn provizantojn, kaj malŝalti iun el ili ne kaŭzos perdon de komunikado kun la Twitch-servilo. Fakte, ĉi tio estas speciala VPN-tunelo, sub kies kapuĉo estas pluraj interretaj kanaloj samtempe. La ĉefa tasko de tia skemo estas akiri la plej altkvalitan komunikadkanalon. Se problemoj komenciĝas ĉe unu el la provizantoj, paka perdo, pliiĝo de prokrastoj, tiam ĉi tio neniel devus influi la kvaliton de komunikado, ĉar la ŝarĝo aŭtomate distribuos sur aliaj pli bonaj kanaloj disponeblaj.
Komercaj Solvoj
Ĉi tiu problemo longe zorgas por tiuj, kiuj elsendas eventojn en vivas kaj ne havas aliron al altkvalita Interreto. Por tiaj taskoj, ekzistas pluraj komercaj solvoj, ekzemple Teradek faras tiajn monstrajn enkursigilojn, en kiuj estas enmetitaj pakoj da USB-modemoj:
Elsenda video-enkursigilo kun kanala sumfunkcio
Tiaj aparatoj kutime havas la kapablon kapti videon per HDMI aŭ SDI. Kune kun la enkursigilo, abono al la kanala sumservo estas vendita, same kiel prilaborado de la videofluo, transkodi ĝin kaj retranssendi ĝin plu. La prezo de tiaj aparatoj komenciĝas de $ 2k kun aro da modemoj, plus aparta abono al la servo.
Kelkfoje ĝi aspektas sufiĉe timiga:
Agordante OpenMPTCPRuter
Protokolo (MultiPath TCP) estis inventita por la kapablo konekti sur pluraj kanaloj samtempe. Ekzemple, lia kaj povas samtempe konektiĝi al fora servilo per WiFi kaj per ĉela reto. Gravas kompreni, ke ĉi tiuj ne estas du apartaj TCP-konektoj, sed unu konekto establita super du kanaloj samtempe. Por ke ĉi tio funkciu, la fora servilo ankaŭ devas subteni MPTCP.
estas malfermfonta programara enkursigilo-projekto, kiu permesas vin vere sumi kanalojn. La aŭtoroj deklaras, ke la projekto estas en alfa versio, sed ĝi jam povas esti uzata. Ĝi konsistas el du partoj - suma servilo, kiu situas en la Interreto kaj enkursigilo, al kiu pluraj interretaj provizantoj kaj klientaj aparatoj mem estas konektitaj: komputiloj, telefonoj. Propra enkursigilo povas esti Raspberry Pi, iuj WiFi-enkursigiloj aŭ regula komputilo. Estas pretaj asembleoj por diversaj platformoj, kio estas tre oportuna.
Kiel funkcias OpenMPTCPRuter
Agordo de resuma servilo
La suma servilo situas en la Interreto kaj finas konektojn de ĉiuj kanaloj de la klienta enkursigilo en unu. La IP-adreso de ĉi tiu servilo estos la ekstera adreso kiam vi aliras la Interreton per OpenMPTCPRuter.
Por ĉi tiu tasko, ni uzos VPS-servilon sur Debian 10.
Postuloj pri sumaj serviloj:
- MPTCP ne funkcias pri virtualigo de OpenVZ
- Eblus instali vian propran Linuksan kernon
La servilo estas deplojita per ekzekuto de unu komando. La skripto instalos la mptcp-ebligitan kernon kaj ĉiujn postulatajn pakaĵojn. Instalaj skriptoj disponeblas por Ubuntu kaj Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
La rezulto de sukcesa servila instalado.
Ni konservas la pasvortojn, ni bezonos ilin por agordi la klientan enkursigilon kaj rekomenci. Gravas memori, ke post instalado, SSH estos disponebla ĉe la haveno 65222. Post rekomenco, ni devas certigi, ke ni ekŝarĉu per la nova kerno.
uname -a
Linux test-server.local 4.19.67-mptcp
Ni vidas la surskribon mptcp apud la numero de versio, kio signifas, ke la kerno estis instalita ĝuste.
Agordi klientan enkursigilon
En Pretaj konstruoj disponeblas por iuj platformoj, kiel Raspberry Pi, Banana Pi, Lynksys-enkursigiloj kaj virtualaj maŝinoj.
Ĉi tiu parto de openmptcprouter estas bazita sur OpenWRT, uzante LuCI kiel interfacon, konata al iu ajn kiu iam renkontis OpenWRT. La dissenda ilaro pezas ĉirkaŭ 50Mb!
Kiel testbenko, mi uzos Raspberry Pi kaj plurajn USB-modemojn kun malsamaj funkciigistoj: MTS kaj Megafon. Kiel skribi bildon al SD-karto, mi supozas, ne necesas diri.
Komence, la Ethernet-haveno en la Raspberry Pi estas agordita kiel lan kun statika IP-adreso. 192.168.100.1. Por ne fuŝi kun la dratoj sur la tablo, mi konektis la Raspberry Pi al WiFi-alirpunkto kaj fiksis statikan adreson sur la WiFi-adaptilo de la komputilo. 192.168.100.2. La DHCP-servilo ne estas ebligita defaŭlte, do statikaj adresoj devas esti uzataj.
Nun vi povas iri al la retinterfaco
Kiam vi unue ensalutas, la sistemo petos vin agordi la radikan pasvorton, SSH estos disponebla kun la sama pasvorto.
En la LAN-agordoj, vi povas agordi la deziratan subreton kaj ebligi la DHCP-servilon.
Mi uzas modemojn kiuj estas difinitaj kiel USB-eterretaj interfacoj kun aparta DHCP-servilo, do ĉi tio bezonata instalado. . La proceduro estas identa al agordo de modemoj en regula OpenWRT, do mi ne kovros ĝin ĉi tie.
Poste, vi devas agordi la WAN-interfacojn. Komence, du virtualaj interfacoj WAN1 kaj WAN2 estis kreitaj en la sistemo. Ili bezonas asigni fizikan aparaton, en mia kazo, ĉi tiuj estas la nomoj de USB-modeminterfacoj.
Por ne konfuziĝi pri la interfaco-nomoj, mi konsilas al vi spekti dmesg-mesaĝojn dum vi estas konektita per SSH.
Ĉar miaj modemoj funkcias kiel enkursigiloj mem kaj mem havas DHCP-servilon, mi devis ŝanĝi la agordojn de iliaj internaj retaj intervaloj kaj malŝalti la DHCP-servilon, ĉar komence ambaŭ modemoj eldonas adresojn el la sama reto, kaj tio kaŭzas konflikton.
OpenMPTCPRuter postulas, ke WAN-interfaco-adresoj estu senmovaj, do ni elpensas subretojn por modemoj kaj agordas ilin en la sistemo → openmptcprouter → interfaco agorda menuo. Ĉi tie vi ankaŭ devas specifi la IP-adreson kaj servilan ŝlosilon akiritan dum la instalado de la suma servilo.
En kazo de sukcesa aranĝo, simila bildo devus aperi sur la statuspaĝo. Oni povas vidi, ke la enkursigilo povis atingi la suman servilon kaj ambaŭ kanaloj funkcias ĝuste.
La defaŭlta reĝimo estas shadowsocks + mptcp. Ĉi tio estas tia prokurilo, kiu envolvas ĉiujn ligojn en si mem. Komence, ĝi estas agordita por trakti nur TCP, sed vi povas ankaŭ ebligi UDP.
Se ne estas eraroj sur la statuspaĝo, la agordo povas esti konsiderata kompleta.
Ĉe iuj provizantoj, situacio povas ekesti kiam la mptcp-flago estas detranĉita laŭ la trafikvojo, tiam estos tia eraro:
En ĉi tiu kazo, vi povas uzi alian operacion, sen uzi MPTCP, pli pri tio .
konkludo
La OpenMPTCPRouter-projekto estas tre interesa kaj grava, ĉar ĝi eble estas la nura malferma kompleksa solvo al la kanala sumproblemo. Ĉio alia estas aŭ firme fermita kaj proprieta, aŭ nur apartaj moduloj, kiujn ordinara homo ne povas trakti. En la nuna etapo de evoluo, la projekto estas ankoraŭ sufiĉe kruda, ekstreme malbona dokumentado, multaj aferoj simple ne estas priskribitaj. Sed samtempe ĝi ankoraŭ funkcias. Mi esperas, ke ĝi daŭre disvolvos, kaj ni ricevos hejmajn enkursigilojn, kiuj povos kombini kanalojn normale el la skatolo.
Sekvu nian programiston ĉe Instagram
fonto: www.habr.com