Kas on võimalik ühendada mitu internetikanalit üheks? Selle teema ümber on palju eksitusi ja müüte, isegi kogenud võrguinsenerid ei tea tihti, et see on võimalik. Enamasti nimetatakse kanalite ühendamiseks ekslikult NAT-i tasemel tasakaalustamist või failover'it. Kuid tõeline summutamine võimaldab edasi saata ühte TCP-ühendust samal ajal läbi kõigi internetikanalite, näiteks videovoolu, nii et ühegi internetikanali katkestamisel ei katkeks edastamine.
Eksisteerivad kallid kommertslahendused videovoolu jaoks, kuid sellised seadmed maksavad palju kilobakste. Artiklis on kirjeldatud tasuta ja avatud paketti OpenMPTCPRouter seadistamist, käsitletakse populaarsed müüdid kanalite summutamise kohta.
Kanalite summutamise müüdid
On palju koduseid ruutereid, mis toetavad Multi-WAN funktsiooni. Mõnikord nimetavad tootjad seda kanalite summutamiseks, mis pole täpselt õige. Paljud võrguinsenerid usuvad, et lisaks ja L2 tasandi summutamisele ei eksisteeri mingit muud kanalite ühendamise võimalust. Olen sageli kuulnud inimestelt, kes töötavad telekomides, et see pole üldse võimalik. Seetõttu proovime uurida populaarseid müüte.
Tasakaalustamine IP-ühenduste tasemel
See on kõige kergem ja populaarsem viis kasutada mitu internetikanalit korraga. Ajutiselt kujutame ette, et teil on kolm internetiteenuse pakkujaga, kellest igaüks annab teile reaalse IP-aadressi oma võrgust. Kõik need teenusepakkujad on ühendatud ruuteri külge, mis toetab Multi-WAN funktsiooni. See võib olla OpenWRT koos mwan3 paketiga, MikroTik, Ubiquiti või mõni muu kodune ruuter, tõenäoliselt on selline valik juba tavaline.
Kujutame ette, et teenusepakkujad andsid meile sellised aadressid:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN3 — 33.33.33.33
St, kui me ühendume kaugsensori külge example.com Iga teenusepakkujat kasutades näeb kaugserver kolme eraldi kliendi source IP-d. Tasakaalustamine võimaldab jagada koormust kanalite vahel ja kasutada kõiki kolme korraga. Kerguse huvides kujutage ette, et jagame koormust võrdselt kõigi kanalite vahel. Seega, kui klient avab saidi, millel on tinglikult kolm pilti, laadib ta iga pildi läbi eraldi teenusepakkuja. Saidi poolel tundub see kui ühendused kolmest erinevast IP-st.
Ühendustaseme tasakaalustamisel läheb iga TCP-ühendus läbi eraldi teenusepakkuja.
Selline tasakaalustamisrežii toob sageli kaasa probleeme kasutajatele. Näiteks seovad paljud saidid küpsised ja tokenid rangelt kliendi IP-aadressiga ning kui see äkitselt muutub, lükatakse päring tagasi või klient logitakse saidilt välja. See esineb sageli kliendipanga süsteemides ja teistel veebisaitidel, kus on ranged kasutajaseansside reeglid. Siin on lihtne visuaalne näide: muusikafailid VK.com-is on saadaval ainult kehtiva seansi võtmega, mis on seotud IP-ga, ja sellist tasakaalustamist kasutavatel klientidel ei mängita sageli heli, kuna päring läks läbi vale teenusepakkuja, kellega seanss on seotud.
Torrente allalaadimisel summeerib ühendustaseme tasakaalustamine kõigi kanalite läbilaskevõimet.
Selline tasakaalustamine võimaldab koguda internetiühenduse kiirus, kui kasutatakse mitut ühendust. Näiteks, kui iga kolme teenusepakkuja kiirus on 100 megabitti, siis torrente allalaadimisel saame 300 megabitti. Sest torrent avab palju ühendusi, mis jaotatakse kõigi teenusepakkujate vahel ning lõpuks kasutatakse kogu kanal.
Oluline on mõista, et üksik TCP-ühendus läbib alati ainult ühe teenusepakkuja. See tähendab, et kui alla laaditakse üks suur fail HTTP kaudu, siis see ühendus tehakse läbi ühe teenusepakkuja, ja kui ühendus selle teenusepakkujaga katke, siis laadimine ka katkeb.
Üks ühendus kasutab alati ainult ühte internetikanalit.
See on kehtib ka videoülekannete puhul. Kui edastate voogedastust mingisugusel Twitch'is, siis IP-ühenduste tasemel tasakaalustamine ei too erilist kasu, kuna video voog edastatakse ühe IP-ühenduse piires. Antud juhul, kui WAN-teenuse pakkujal tekivad sideprobleemid, näiteks pakettide kaotused või kiiruslangus, ei saa te kohe teisele teenuse pakkujale üle minna. Ülekannet tuleb peatada ja uuesti sisse logida.
Reaalne kanalite summeerimine
Reaalne kanalite summeerimine võimaldab teil saata ühe ühenduse Twitch'ile läbi kõigi teenuse pakkujate, nii et kui mõni teenuse pakkuja kukub, ei katke ühendus. See on üllatavalt keeruline ülesanne, millele ei ole endiselt optimaalselt lahendust. Paljud ei tea isegi, et see on võimalik!
Eelnevatest illustratsioonidest mäletame, et Twitch'i server saab meilt video voogu ainult ühe allika IP-aadressilt, mis tähendab, et see peab olema pidev, sõltumata sellest, millised teenuse pakkujad katkestavad ja millised töötavad. Selle saavutamiseks vajame summeeriva serverit, mis terminib kõik meie ühendused ja ühendab need ühte.
Summeeriv server koondab kõik kanalid ühte tunnelisse. Kõik ühendused toimuvad summeeriva serveri aadressilt.
Sellises skeemis kasutatakse kõiki teenuse pakkujaid ning ühe käivitamine ei põhjusta ühenduse katkestamist Twitch'i serveriga. Sisuliselt on see eriline VPN-tunnel, mille all on mitu internetiühendust. Sellise skeemi peamine ülesanne on saavutada võimalikult kõrge kvaliteediga sidekanal. Kui mõnes teenuse pakkujas tekivad probleemid, pakettide kaotamine, viivituste suurenemine, ei tohiks see kuidagi mõjutada side kvaliteeti, kuna koormus jaotatakse automaatselt parematele kanalitele, mis on olemas.
Ärilahendused
See probleem on ammu murettekitav neile, kes viivad läbi otseülekandeid ja kellel ei ole juurdepääsu kvaliteetsele internetile. Selliste ülesannete jaoks leidub mitmeid ärilisi lahendusi, näiteks Teradeki ettevõte toodab selliseid monstrumlike ruutereid, kuhu on paigaldatud hulk USB modemite.
Videovooder, millel on kanalisummamise funktsioon
Nendes seadmetes on tavaliselt sisseehitatud HDMI või SDI vide_signaali haaramise võimalus. Koos ruuteriga müüakse samuti tellimus kanalite kokkuvõtte teenusele ning videovoogude töötlemise, koodimise ja edasi saatmise teenusele. Selliste seadmete hind algab 2000 dollarist koos modemite komplekti, pluss eraldi tellimus teenusele.
Mõnikord näeb see piisavalt hirmutav välja:
Seame üles OpenMPTCPRouteri
Protokoll (MultiPath TCP) on välja mõeldud võimaluse jaoks ühendada korraga mitu kanalit. Näiteks, see ja võib samal ajal ühendada kaugsüsteemiga WiFi ja mobiilside võrgu kaudu. Oluline on mõista, et need ei ole kaks eraldi TCP-ühendust, vaid üks ühendus, mis luuakse kohe kahe kanali kaudu. Selleks, et see töötaks, peab kaugserver ka toetama MPTCP-d.
on avatud projekt, mis on tarkvararuuter, mis võimaldab tõeliselt kanaleid kokku liita. Autorid väidavad, et projekt on veel alfa-üksuses, kuid seda saab juba kasutada. See koosneb kahest osast - summimise serverist, mis asub internetis ja ruuterist, millele on ühendatud mitu internetiteenuse pakkujat ja kliendiseadmed: arvutid, telefonid. Kasutajaruuterina võib kasutada Raspberry Pi, mõned WiFi-ruuterid või tavalist arvutit. Erinevate platvormide jaoks on saadaval valmis kompositsioonid, mis on väga mugavad.
OpenMPTCPRouteri tööpõhimõte
Summitava serveri seadistamine
Summitav server asub internetis ja lõpetab ühendused kõigist klientruuteri kanalitest ühte. Selle serveri IP-aadress on OpenMPTCPRouteri kaudu Internetti sisenedes välised aadressid.
Selle ülesande jaoks kasutame VPS-serverit Debian 10-l.
Summitava serveri nõuded:
- MPTCP ei tööta OpenVZ virtualiseerimise peal
- Peab olema võimalik paigaldada oma Linuxi kerneli
Serveri käivitamine toimub ühe käsu täitmisega. Skript paigaldab mptcp toe ja kõik vajalikud paketid. Paigaldus skriptid on saadaval Ubuntu ja Debian jaoks.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Serveri eduka paigaldamise tulemus.
Salvestame paroolid, neid on vaja kliendi ruuteri seadistamiseks ning taaskäivitame. Oluline on meeles pidada, et pärast SSH installimist on see saadaval sadamal 65222. Pärast taaskäivitamist tuleb veenduda, et oleme uusima tuumaga üles laaditud.
uname -a
Linux test-server.local 4.19.67-mptcp
Näeme, et versiooni numbri kõrval on kiri mptcp, mis tähistab, et tuum on õigesti installitud.
Kliendi ruuteri seadistamine
Pealehe valmis kogumid on saadaval mõnedele platvormidele, näiteks Raspberry Pi, Banana Pi, Lynksys ruutereid ja virtuaalmasinaid.
See osa openmptcprouterist põhineb OpenWRT-l, liidesena kasutatakse LuCI-d, mis on tuttav kõigile, kes on kunagi OpenWRT-ga kokku puutunud. Jaotuse suurus on umbes 50Mb!
Testseadmena kasutan Raspberry Pi-d ja mitmeid USB-modemeid erinevate operaatoritega: MTS ja MegaFon. Kuidas kirjutada pilt SD-kaardile, arvan, et ei pea rääkima.
Algselt on Raspberry Pi Ethernet-port seadistatud LAN-ina staatilise IP-aadressiga. 192.168.100.1. Et mitte köögilaual juhtmetega jamada, ühendasin Raspberry Pi WiFi juurdepääsupunktiga ja määrasin arvuti WiFi-adapterile staatilise aadressi. 192.168.100.2. Vaikimisi ei ole DHCP-server sisse lülitatud, seega tuleb kasutada staatilisi aadresse.
Nüüd on võimalik minna veebiliidesesse.
Esimese sisselogimise korral palub süsteem määrata root parooli, sama parooliga on saadaval ka SSH.
LAN-i seadetes saab määrata soovitud alamvõrgu ja aktiveerida DHCP-serveri.
Kasutangi modemid, mis tuvastatakse kui USB Ethernet liidesed, millel on eraldi DHCP-server, seega oli vajalik installida . Protseduur on identne modemite seadistamisega tavalisel OpenWRT-l, seega ei hakka ma seda siin käsitlema.
Seejärel tuleb seadistada WAN-liidesed. Alguses on süsteemis loodud kaks virtuaalset liidest WAN1 ja WAN2. Nendele tuleb määrata füüsiline seade, minu juhul on need USB-modemite liidese nimed.
Kuna ma ei soovi liideste nimedes segadusse sattuda, soovitan vaadata dmesg sõnumeid, ühendudes SSH kaudu.
Kuna minu modemid toimivad ise ruuteritena ja neil on oma DHCP-server, pidin muutma nende sisemiste võrguvahemike seadeid ja välja lülitama DHCP-serveri, kuna algselt jagavad mõlemad modemid aadresse ühest võrgust ja see tekitab konflikti.
OpenMPTCPRouter nõuab, et WAN-liideste aadressid oleksid staatilised, seetõttu määrame modemitele alamvõrgud ja seadistame menüüs system → openmptcprouter → interface settings. Siin tuleb samuti märkida IP-aadress ja serveri võtme, mis saadi kogumiserveri seadistamise käigus.
Eduka seadistamise korral peaks oleku lehel ilmuma sarnane pilt. Näha on, et ruuter on suutnud ühendust saada kogumiserveriga ja mõlemad kanalid töötavad normaalselt.
Vaikimisi kasutatakse režiimi shadowsocks + mptcp. See on selline proxy, mis katab kõik ühendused. Algaja seadistus töötleb ainult TCP, kuid samuti on võimalik lubada ka UDP.
Kui oleku lehel ei ole vigu, võib seadistuse lõpetatuks lugeda.
Mõne teenusepakkujaga võib esineda olukordi, kus liikluse teekonnal lõigatakse mptcp lipp ära, siis ilmneb selline viga:
Sel juhul on võimalik kasutada teist töörežiimi, ilma MPTCP kasutamata, rohkem teavet selle kohta .
Kokkuvõte
Projekt OpenMPTCPRouter on väga huvitav ja oluline, kuna see on ilmselt ainus avatud kompleksne lahendus kanalite kokkuvõtte probleemiks. Kõik muu on kas täielikult suletud ja omandiõiguslik või lihtsalt eraldi moodulid, millega tavaline inimene ei suuda toime tulla. Praegusel arenguetapil on projekt veel piisavalt toore, äärmiselt napp dokumentatsioon, paljusid asju pole lihtsalt kirjeldatud. Kuid see töötab siiski. Loodan, et projekt jätkab arengut ja saame kodu ruuterid, mis oskavad kanaleid normaalselt ühendada juba karbist väljas.
Jälgi meie arendajat Instagramis
Allikas: habr.com
