Kas on võimalik ühendada mitu Interneti-kanalit üheks? Selle teema ümber on palju väärarusaamu ja müüte, isegi kogenud võrguinsenerid ei tea sageli, et see on võimalik. Enamikul juhtudel nimetatakse linkide koondamist ekslikult NAT-i tasakaalustamiseks või tõrkesiirdeks. Kuid tõeline summeerimine võimaldab käivitada üheainsa TCP-ühenduse kõigis Interneti-kanalites, näiteks videoedastus, et kui mõni Interneti-kanalitest katkeb, siis ülekanne ei katkeks.
Videoülekannete jaoks on kalleid kommertslahendusi, kuid sellised seadmed maksavad palju kilobucks. Artiklis kirjeldatakse tasuta avatud paketi OpenMPTCPRuter konfiguratsiooni ja käsitletakse populaarseid müüte kanalite summeerimise kohta.
Müüdid kanalite summeerimise kohta
Multi-WAN-funktsiooni toetavaid koduruutereid on palju. Mõnikord nimetavad tootjad seda kanalit summeerimiseks, mis pole täiesti tõsi. Paljud võrgutegijad usuvad, et lisaks
Tasakaalustamine IP ühenduste tasemel
See on kõige soodsam ja populaarseim viis mitme Interneti-kanali samaaegseks kasutamiseks. Lihtsuse huvides kujutame ette, et teil on kolm Interneti-teenuse pakkujat, millest igaüks annab teile oma võrgust tõelise IP-aadressi. Kõik need pakkujad on ühendatud ruuteriga, mis toetab funktsiooni Multi-WAN. See võib olla OpenWRT koos mwan3 paketiga, mikrotik, ubiquiti või mõni muu majapidamisruuter, kuna nüüd pole see valik enam haruldane.
Olukorra simuleerimiseks kujutage ette, et teenusepakkujad andsid meile järgmised aadressid:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
See tähendab ühenduse loomist kaugserveriga example.com iga pakkuja kaudu näeb kaugserver kliendi kolme sõltumatut lähtekoodi. Tasakaalustamine võimaldab jagada koormust kanalite vahel ja kasutada neid kõiki kolme korraga. Lihtsuse huvides kujutame ette, et jagame koormuse kõigi kanalite vahel võrdselt. Selle tulemusena, kui klient avab tingimuslikult kolme pildiga saidi, laadib ta iga pildi alla eraldi teenusepakkuja kaudu. Saidi poolel näeb see välja nagu ühendused kolmest erinevast IP-st.
Ühenduse tasemel tasakaalustamisel läbib iga TCP-ühendus eraldi pakkuja.
See tasakaalustamisrežiim põhjustab kasutajatele sageli probleeme. Näiteks ühendavad paljud saidid kliendi IP-aadressile küpsised ja märgid ning kui see ootamatult muutub, taotlus tühistatakse või klient logib saidilt välja. Seda korratakse sageli kliendi-panga süsteemides ja muudel rangete kasutajaseansireeglitega saitidel. Siin on lihtne illustreeriv näide: VK.com-i muusikafailid on saadaval ainult kehtiva seansivõtmega, mis on seotud IP-ga, ja sellist tasakaalustamist kasutavad kliendid sageli heli ei esita, kuna päring ei jõudnud teenusepakkuja kaudu, kellele seanss on seotud.
Torrentide allalaadimisel summeerib ühenduse tasemel tasakaalustamine kõigi kanalite ribalaiuse
Selline tasakaalustamine võimaldab saada Interneti-kanali kiiruse summeerimist mitme ühenduse kasutamisel. Näiteks kui kõigil kolmel pakkujal on kiirus 100 megabitti, siis torrentide allalaadimisel saame 300 megabitti. Kuna torrent avab palju ühendusi, mis jagunevad kõigi pakkujate vahel ja kasutavad lõpuks kogu kanalit.
Oluline on mõista, et üks TCP-ühendus läbib alati ainult ühe pakkuja. See tähendab, et kui laadime alla ühe suure faili HTTP kaudu, siis see ühendus luuakse ühe pakkuja kaudu ja kui ühendus selle pakkujaga katkeb, katkeb ka allalaadimine.
Üks ühendus kasutab alati ainult ühte Interneti-kanalit
See kehtib ka videoülekannete kohta. Kui edastate voogedastusvideot mõnes tingimuslikus Twitchis, siis IP-ühenduste tasemel tasakaalustamine erilist kasu ei anna, kuna videovoog edastatakse ühe IP-ühenduse piires. Sel juhul, kui WAN 3 pakkujal tekivad sideprobleemid, näiteks pakettide kadumine või aeglustumine, ei saa te kohe teisele pakkujale lülituda. Ülekanne tuleb peatada ja uuesti ühendada.
Tõeline kanalite kokkuvõte
Kanalite reaalne liitmine võimaldab käivitada ühe ühenduse tingimusliku Twitchiga läbi kõigi pakkujate korraga nii, et kui mõni pakkuja katki läheb, siis ühendus ei katke. See on üllatavalt keeruline probleem, millele pole siiani optimaalset lahendust. Paljud isegi ei tea, et see on võimalik!
Eelnevatest illustratsioonidest mäletame, et tingimuslik Twitchi server võib meilt videovoogu vastu võtta vaid ühelt lähte-IP-aadressilt, mis tähendab, et see peab alati meie juures olema konstantne, olenemata sellest, millised pakkujad on ära kukkunud ja millised töötavad. Selle saavutamiseks vajame summeerimisserverit, mis katkestab kõik meie ühendused ja liidab need üheks.
Summeerimisserver koondab kõik kanalid ühte tunnelisse. Kõik ühendused pärinevad summeerimisserveri aadressilt
See skeem kasutab kõiki pakkujaid ja ühegi neist keelamine ei põhjusta side katkemist Twitchi serveriga. Tegelikult on see spetsiaalne VPN-tunnel, mille kapoti all on korraga mitu Interneti-kanalit. Sellise skeemi peamine ülesanne on saada kõrgeima kvaliteediga sidekanal. Kui probleemid algavad mõne pakkuja juures, pakettide kadu, viivituste suurenemine, siis ei tohiks see kuidagi mõjutada suhtluskvaliteeti, kuna koormus jaotub automaatselt üle teiste saadaolevate paremate kanalite.
Kaubanduslikud lahendused
See probleem on pikka aega muret tekitanud neile, kes edastavad sündmusi otseülekandes ja kellel puudub juurdepääs kvaliteetsele Internetile. Selliste ülesannete jaoks on mitmeid kommertslahendusi, näiteks teeb Teradek selliseid koletuid ruutereid, millesse sisestatakse USB-modemipaketid:
Saate videoruuter kanalite summeerimise funktsiooniga
Tavaliselt on sellistel seadmetel võimalus jäädvustada videot HDMI või SDI kaudu. Koos ruuteriga müüakse kanalite summeerimisteenuse tellimust, samuti videovoo töötlemist, ümberkodeerimist ja edasist taasedastamist. Selliste seadmete hind algab 2 XNUMX dollarist koos modemikomplektiga, millele lisandub teenuse eraldi tellimus.
Mõnikord tundub see üsna hirmutav:
OpenMPTCPRuteri seadistamine
Protokoll
Kuidas OpenMPTCPRuter töötab
Kokkuvõtte serveri seadistamine
Summeerimisserver asub Internetis ja lõpetab ühendused kõigist klientruuteri kanalitest üheks. Selle serveri IP-aadress on OpenMPTCPRuteri kaudu Internetti pääsemisel välisaadress.
Selle ülesande jaoks kasutame Debian 10 VPS-serverit.
Nõuded summeerimisserverile:
- MPTCP ei tööta OpenVZ virtualiseerimisel
- Peaks olema võimalik installida oma Linuxi kernel
Server juurutatakse ühe käsu täitmisega. Skript installib mptcp-toega kerneli ja kõik vajalikud paketid. Installimisskriptid on saadaval Ubuntu ja Debiani jaoks.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Eduka serveri installimise tulemus.
Salvestame paroolid, vajame neid kliendi ruuteri konfigureerimiseks ja taaskäivitamiseks. Oluline on meeles pidada, et pärast installimist on SSH saadaval pordis 65222. Pärast taaskäivitamist peame veenduma, et käivitame uue kerneliga
uname -a
Linux test-server.local 4.19.67-mptcp
Näeme versiooninumbri kõrval kirja mptcp, mis tähendab, et kernel oli õigesti installitud.
Kliendiruuteri seadistamine
Edasi
Openmptcprouteri see osa põhineb OpenWRT-l, kasutades liidesena LuCI-d, mis on tuttav kõigile, kes on kunagi OpenWRT-ga kokku puutunud. Jaotuskomplekt kaalub umbes 50Mb!
Testipingina kasutan Raspberry Pi ja mitut erinevate operaatoritega USB modemit: MTS ja Megafon. Kuidas SD-kaardile pilti kirjutada, pole vist vaja öelda.
Algselt on Raspberry Pi Etherneti port konfigureeritud staatilise IP-aadressiga kohtvõrguna. 192.168.100.1. Et laual olevate juhtmetega mitte jamada, ühendasin Raspberry Pi WiFi pääsupunktiga ja panin arvuti WiFi adapterile staatilise aadressi 192.168.100.2. DHCP-server ei ole vaikimisi lubatud, seega tuleb kasutada staatilisi aadresse.
Nüüd saate minna veebiliidesele
Esmakordsel sisselogimisel palub süsteem teil määrata juurparool, SSH on saadaval sama parooliga.
LAN-i sätetes saate määrata soovitud alamvõrgu ja lubada DHCP-serveri.
Kasutan modemeid, mis on määratletud USB etherneti liidestena eraldi DHCP-serveriga, nii et see nõudis installimist
Järgmisena peate konfigureerima WAN-liidesed. Algselt loodi süsteemi kaks virtuaalset liidest WAN1 ja WAN2. Nad peavad määrama füüsilise seadme, minu puhul on need USB-modemi liideste nimed.
Et liideste nimedes mitte segadusse sattuda, soovitan teil SSH kaudu ühenduses olles vaadata dmesg-sõnumeid.
Kuna minu modemid toimivad ise ruuteritena ja neil on ka DHCP server, siis pidin muutma nende sisevõrgu vahemike sätteid ja keelama DHCP serveri, kuna esialgu annavad mõlemad modemid samast võrgust aadresse ja see tekitab konflikti.
OpenMPTCPRuter nõuab, et WAN-liidese aadressid oleksid staatilised, seega mõtleme välja modemitele alamvõrgud ja konfigureerime need süsteemis → openmptcprouter → liidese seadete menüü. Siin peate määrama ka summeerimisserveri installimisel saadud IP-aadressi ja serveri võtme.
Eduka seadistamise korral peaks sarnane pilt ilmuma olekulehele. On näha, et ruuter jõudis summeerimisserverisse ja mõlemad kanalid töötavad korralikult.
Vaikerežiim on shadowsocks + mptcp. See on selline puhverserver, mis mähib kõik ühendused endasse. Algselt on see konfigureeritud käsitlema ainult TCP-d, kuid saate lubada ka UDP.
Kui olekulehel pole vigu, võib seadistuse lugeda lõpetatuks.
Mõne teenusepakkuja puhul võib tekkida olukord, kui mptcp lipp kärbitakse mööda liiklusteed, siis tekib selline tõrge:
Sel juhul saate kasutada mõnda muud töörežiimi ilma MPTCP-d kasutamata
Järeldus
OpenMPTCPRuteri projekt on väga huvitav ja oluline, kuna see on võib-olla ainus avatud komplekslahendus kanalite liitmise probleemile. Kõik muu on kas tihedalt suletud ja varaline või lihtsalt eraldi moodulid, millega tavainimene hakkama ei saa. Praeguses arendusjärgus on projekt veel üsna toores, äärmiselt kehv dokumentatsioon, paljud asjad on lihtsalt kirjeldamata. Kuid samal ajal see ikkagi töötab. Loodan, et see areneb edasi ja saame karbist välja majapidamisruuterid, mis suudavad tavapäraselt kanaleid kombineerida.
Jälgi meie arendajat Instagramis
Allikas: www.habr.com