Kas on võimalik ühendada mitu internetiühendust üheks? Selle teema ümber on palju väärarusaamu ja müüte, isegi kogenud võrgueksperdid ei tea sageli, et see on võimalik. Enamasti tuntakse kanalite ühendamist vale nime all, nagu NAT tasemel koormuse tasakaalustamine või varukoopia. Kuid tõeline summaarne ühendamine võimaldab saata ühte TCP-ühendust korraga üle kõik internetiühendused, näiteks videovoogedastust nii, et ükskõik millisest internetiühendusest katkestamine ei katkestaks edastamist.
On olemas kallid kaubanduslikud lahendused videovoogedastuseks, kuid sellised seadmed maksavad palju tuhandeid eurosid. Artiklis käsitletakse tasuta avatud OpenMPTCPRouter paketi seadistamist ning arutatakse populaarseid müüte kanalite ühendamise kohta.
Mütoloogiad kanalite ühendamisest
On palju odavaid ruutereid, mis toetavad Multi-WAN funktsiooni. Mõnikord nimetavad tootjad seda kanalite ühendamiseks, mis pole päris õige. Paljud võrgueksperdid usuvad, et lisaks ja tasakaalu saavutamine L2 tasemel, ei ole mingit muud kanalite ühendamist. Olen sageli kuulnud, et see on täielikult võimatu inimestelt, kes töötavad telekomis. Seega proovime uurida populaarsuse müüte.
IP-ühenduste tasemel koormuse jagamine
See on kõige taskukohasem ja populaarsem viis kasutada mitut internetikanalit korraga. Lihtsuse huvides kujutame ette, et teil on kolm interneti teenusepakkujat, igaüks annab teile oma võrgust reaalse IP-aadressi. Kõik need teenusepakkujad on ühendatud marsruuterisse, mis toetab Multi-WAN funktsiooni. See võib olla OpenWRT koos mwan3 paketiga, Mikrotik, Ubiquiti või mõni muu kodune marsruuter, kuna nüüd on selline valik juba tavaliseks muutunud.
Situatsiooni modelleerimiseks kujutame ette, et teenusepakkujad on meile andnud järgmised aadressid:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN3 — 33.33.33.33
Kuna ühendume eemaloleva serveriga example.com Iga teenusepakkuja kaudu näeb kaugserver kolme sõltumatut kliendi allika IP-aadressi. Koormuse jaotamine võimaldab jagada koormust kanalite vahel ja kasutada neid kõiki kolme samaaegselt. Lihtsuse huvides kujutame ette, et jagame koormuse kõikide kanalite vahel võrdselt. Tulemuseks on see, et kui klient avab lehe, kus on näiteks kolm pilti, laadib ta iga pildi läbi erineva teenusepakkuja. Veebilehe poolelt näeb see välja nagu kolm erinevat IP-aadressi, mis on ühendatud.
Ühendusleveli tasemel koormuse jaotamise puhul toimub iga TCP-ühendus läbi eraldi teenusepakkuja.
Selline tasakaalustusrežiim toob sageli kaasa probleeme kasutajatele. Näiteks seovad paljud veebisaidid küpsised ja tokenid kindlalt kliendi IP-aadressiga, ning kui see äkitselt muutub, lükatakse päring tagasi või logib klient veebisaidilt välja. See esineb sageli kliendi pangandussüsteemides ja muudel veebisaitidel, kus kehtivad ranged kasutajasessioonide reeglid. Siin on lihtne näide: muusikafailid VK.com-is on kättesaadavad ainult kehtiva sessioonivõtmega, mis on seotud IP-aadressiga, ja sellist tasakaalu kasutavatel klientidel ei mängita sageli heli, kuna päring saadeti mitte selle teenusepakkuja kaudu, kellega seanss on seotud.
Torrentide allalaadimisel summutab ühendustasandi tasakaalustus kõikide kanalite ribalaiuse.
Selline tasakaalustus võimaldab internetiühenduse kiirusel kumuleeruda, kasutades mitmeid ühendusi. Näiteks, kui igal kolmel teenusepakkujal on kiirus 100 megabitti, siis torrentide allalaadimisel saame tulemuseks 300 megabitti. See, kuna torrent avab hulgaliselt ühendusi, mis jagunevad kõigi teenusepakkujate vahel ning lõpuks kasutavad kogu ühenduse ära.
Oluline on mõista, et üksainus TCP-ühendus läbib alati vaid ühte teenusepakkujat. See tähendab, et kui allalaadime ühte suurt faili HTTP kaudu, siis see ühendus toimub läbi ühe teenusepakkuja, ja kui side selle teenusepakkujaga katkeb, siis ka allalaadimine katkeb.
Üks ühendus kasutab alati ainult ühte internetikanalit.
See on tõene ka videovalamiste puhul. Kui edastate voogedastust näiteks Twitchis, ei tooda IP-ühenduste tasemel tasakaalustamine mingit erilist kasu, kuna video voog edastatakse ühe IP-ühenduse sees. Sel juhul, kui WAN-i pakkujal tekivad sideprobleemid, nagu paketikaod või kiiruslangus, ei saa te kohe teisele pakkujale üle minna. Edastust tuleb peatada ja uuesti ühendust luua.
Reaalne kanalite summeerimine
Reaalne kanalite summeerimine võimaldab suunata ühe ühenduse näiteks Twitchi kaudu läbi kõigi pakkujate nii, et kui ükskõik milline pakkuja läheb katki, ei katke ühendus. See on üllatavalt keeruline ülesanne, millel pole siiani optimaalset lahendust. Paljud ei teagi, et see on võimalik!
Eelmiste illustratsioonide põhjal mäletame, et tinglik Twitch server võib vastu võtta videovooge ainult ühelt source IP aadressilt, seega peab see olema meil alati stabiilne, olenemata sellest, millised teenusepakkujad on katkestatud ja millised töötavad. Selle saavutamiseks vajame summatiivset serverit, mis lõpetab kõik meie ühendused ja ühendab need üheks.
Summatiivne server koondab kõik kanalid ühte tunnelisse. Kõik ühendused toimuvad summatiivse serveri aadressilt.
Sellises skeemis kasutatakse kõiki teenusepakkujaid, ning mis tahes neist katkestamine ei põhjusta ühenduse katkemist Twitch serveriga. Sisuliselt on see eriline VPN-tunnel, mille all on mitmed internetikanalid. Selle skeemi peamine ülesanne on saada maksimaalselt kvaliteetne sidekanal. Kui mõnel teenusepakkujatel tekivad probleemid, paketikaod või viivituste suurenemine, siis ei tohiks see kvaliteeti kuidagi mõjutada, sest koormus jaotatakse automaatselt muudele, kvaliteetsematele kanalitele, mis on meie käsutuses.
Kaubanduslikud lahendused
See probleem on juba ammu vaevanud neid, kes edastavad üritusi ja kellel puudub ligipääs kvaliteetsele internetile. Sellisteks ülesanneteks on olemas mitmeid kaubanduslikke lahendusi; näiteks valmistab ettevõte Teradek tohutuid ruutereid, kuhu saab lisada terveid gruppe USB-modemeid.
Videovoo ruuter kanali summeerimise funktsiooniga
Sellistes seadmetes on tavaliselt sisseehitatud video signaali salvestamise võimalus HDMI või SDI kaudu. Koos ruuteriga müüakse tellimus kanali summeerimise teenusele, samuti videovoo töötlemise, kodeerimise ja edastamise teenusele. Selliste seadmete hind algab 2000 dollarist koos modemitest koosneva komplektiga, pluss eraldi tellimus teenusele.
Mõnikord võib see tunduda üsna hirmuäratav:
Seame üles OpenMPTCPRouter
Protokoll (MultiPath TCP) on välja töötatud võimaluseks ühendada korraga mitme kanaliga. Näiteks, seda ja võib samal ajal ühendada kaugsüsteemiga nii WiFi kui ka mobiilse võrgu kaudu. Oluline on mõista, et need ei ole kaks eraldi TCP-ühendust, vaid üks ühendus, mis on loodud kahe kanali kaudu. Selle toimimiseks peab kaugsüsteem ka toetama MPTCP-d.
on avatud programmiline ruuter, mis võimaldab tõeliselt summutada kanaleid. Autorite sõnul on projekt alfa-etapis, kuid seda saab juba kasutada. See koosneb kahest osast - summutavast serverist, mis asub internetis, ja ruuterist, mille kaudu on ühendatud mitu interneti pakkujat ja kliendiseadmed: arvutid, telefonid. Kasutajaruuterina võib toimida Raspberry Pi, mõned WiFi-ruuterid või tavaline arvuti. On olemas valmis kogumikud erinevatele platvormidele, mis on väga mugav.
OpenMPTCPRouteri tööpõhimõte
Summutava serveri seadistamine
Summutav server asub internetis ja terminalib ühendused kõigilt kliendi ruuteri kanalitelt ühte. Selle serveri IP-aadress on välisadresseering internetti pääsemiseks läbi OpenMPTCPRouteri.
Selle ülesande jaoks kasutame VPS-serverit Debian 10-l.
Kokkuvõtva serveri nõuded:
- MPTCP ei tööta OpenVZ virtualiseerimisel
- Peab olema võimalik installida oma Linuxi kernel
Serveri juurutamine toimub ühe käsu täitmisega. Skript installib kernelit MPTCP toe ja kõik vajalikud paketid. Installatsiooniskriptid on saadaval Ubuntu ja Debian'i jaoks.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Serveri eduka installimise tulemus.
Salvestame paroolid, need on vajalikud kliendi ruuteri seadistamiseks, ja taaskäivitame. Oluline on meeles pidada, et pärast installimist on SSH saadaval pordil 65222. Pärast taaskäivitamist tuleb veenduda, et oleme käivitatud uue kerneliga
uname -a
Linux test-server.local 4.19.67-mptcp
Näeme versiooninumbri kõrval mptcp märget, mis tähendab, et kernel on õigesti installitud.
Kliendi ruuteri seadistamine
VDS-l on võimalik installida: Valmis ehitused on saadaval mõnedele platvormidele, näiteks Raspberry Pi, Banana Pi, Linksysi ruuteritele ja virtuaalmasinatele.
See osa openmptcprouterist põhineb OpenWRT-l, kasutades liidesena LuCI-d, millega on tuttav igaüks, kes on kunagi OpenWRT-ga kokku puutunud. Jaotus kaalub umbes 50 MB!
Testimise seadmena kasutan Raspberry Pi-d ja mitut USB-moodulit erinevate operaatoritega: MTS ja MegaFon. Kuidas kirjutada pilt SD-kaardile, arvan, et ei pea rääkima.
Algselt on Raspberry Pi Ethernet-port seadistatud nagu lan staatilise IP-aadressiga. 192.168.100.1. Et laual kaablite kallal ei toimetada, ühendasin Raspberry Pi WiFi juurdepääsupunktiga ja määrasin arvuti WiFi-adapterile staatilise aadressi. 192.168.100.2. Vaikimisi DHCP-server ei ole sisse lülitatud, seega tuleb kasutada staatilisi aadresse.
Nüüd saab siseneda veebiliidesesse.
Esimese sisenemise korral palub süsteem seadistada root-parool, millega on samuti saadaval SSH.
LAN-seadetes saab määrata vajaliku alamvõrgu ja lubada DHCP-serveri.
Kasutatakse modemite, mida tuvastatakse kui USB Etherneti liideseid eraldi DHCP-serveriga, seega see nõudis täiendavate paketide installimist. . Protseduur on sama, mis tavapäraste OpenWRT modemite seadistus, seega ei käsitle ma seda siin.
Seejärel tuleb seadistada WAN-liideseid. Alguses on süsteemis loodud kaks virtuaalset liidest WAN1 ja WAN2. Neile tuleb määrata füüsiline seade, minu puhul on need USB-mooduli liideste nimed.
Kuna interface'ide nimed võivad segadusse ajada, soovitan vaadata dmesg sõnumeid, ühendudes SSH kaudu.
Kuna mu modemid toimivad ise ruuteritena ja neil on DHCP-server, pidin muutma nende sisevõrkude seadeid ja DHCP-serveri välja lülitama, kuna algselt andsid mõlemad modemid aadresse samast võrgust, mis põhjustas konflikti.
OpenMPTCPRouter nõuab, et WAN-interface'ide aadressid oleksid staatilised, seega määrame modemitele alamvõrgud ja seadistame menüüs system → openmptcprouter → interface settings. Siin tuleb samuti täpsustada IP-aadress ja serveri võti, mis saadi summitamise serveri seadistamise etapil.
Kui seaded on õigesti konfigureeritud, peaks olekulehe peal olema sarnane pilt. Nähtavasti suutis ruuter ühendust saada summitamise serveriga ja mõlemad kanalid töötavad normaalselt.
Vaikimisi kasutatakse režiimi shadowsocks + mptcp. See on proxy, mis pakib endasse kõik ühendused. Alguses on see seadistatud töötama ainult TCP-ga, kuid UDP-d saab ka lubada.
Kui olekulehe peal pole vigu, võib seadistust lugeda lõpetatuks.
Mõnede teenusepakkujatega võib juhtuda, et liikluse teel kärbitakse mptcp lipp, mille tõttu tekib selline viga:
Sel juhul saab kasutada teistsugust töörežiimi, ilma MPTCP kasutamiseta, rohkem teavet selle kohta .
Kokkuvõte
OpenMPTCPRouter projekt on väga huvitav ja oluline, kuna see on tõenäoliselt ainus avatud terviklik lahendus kanalite summeerimise probleemile. Kõik muu on kas täielikult suletud ja patenteeritud või lihtsalt eraldi moodulid, millega tavaline inimene ei saa hakkama. Praegusel arengu etapil on projekt siiski üsna toores, äärmiselt napp dokumentatsioon ja paljusid asju lihtsalt ei ole kirjeldatud. Kuid samas töötab see siiski. Loodan, et see jätkab arengut ja saame koduste ruuterite, mis oskavad katkestusteta kanaleid ühendada.
Jälgige meie arendajat Instagramis
Allikas: habr.com
