{"id":53735,"date":"2019-12-09T00:00:00","date_gmt":"2019-12-08T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/nastoyashhee-summirovanie-internet-kanalov-openmptcprouter"},"modified":"2020-02-18T14:01:40","modified_gmt":"2020-02-18T11:01:40","slug":"nastoyashhee-summirovanie-internet-kanalov-openmptcprouter","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/nastoyashhee-summirovanie-internet-kanalov-openmptcprouter","title":{"rendered":"Pravi zbir internet kanala \u2014 OpenMPTCPRouter","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Pravi
\n
\nMo\u017ee li se vi\u0161e internet kanala spojiti u jedan? Oko ove teme postoji mnogo zabluda i mitova, \u010dak i iskusni mre\u017eni in\u017eenjeri \u010desto nisu svesni da je to mogu\u0107e. U ve\u0107ini slu\u010dajeva, spoj na kanale pogre\u0161no nazivaju balansiranjem na nivou NAT-a ili failover-om. No, pravo sumiranje omogu\u0107ava da se jedno jedino TCP povezivanje simultano koristi kroz sve internet kanale<\/b>, na primer za video prenos, tako da se prenos ne prekida prilikom gubitka bilo kojeg od internet kanala. <\/p>\n

Postoje skupa komercijalna re\u0161enja za video prenose, ali takvi ure\u0111aji ko\u0161taju mnogo hiljada dolara. U tekstu se opisuje pode\u0161avanje besplatnog, otvorenog paketa OpenMPTCPRouter, razbija se popularne mitove o sumiranju kanala.
\n<\/a><\/noindex><\/p>\n

Mitovi o sumiranju kanala<\/h2>\n

\nPostoji mnogo potro\u0161a\u010dkih rutera koji podr\u017eavaju funkciju Multi-WAN. Ponekad je proizvo\u0111a\u010di nazivaju sumiranjem kanala, \u0161to nije sasvim ta\u010dno. Mnogi mre\u017eni stru\u010dnjaci veruju da osim LACP<\/a><\/noindex> i sumiranja na L2 nivou, ne postoji drugo spajanje kanala. \u010cesto sam \u010duo da je to uop\u0161te nemogu\u0107e od ljudi koji rade u telekomunikacijama. Zato hajde da raspravimo o popularnim mitovima. <\/p>\n

Balansiranje na nivou IP povezivanja<\/h2>\n

\nTo je najpristupa\u010dniji i najpopularniji na\u010din kori\u0161\u0107enja vi\u0161e internet kanala simultano. Radi jednostavnosti, zamislimo da imate tri internet provajdera, svaki od njih vam dodeljuje stvarnu IP adresu iz svoje mre\u017ee. Svi ovi provajderi su priklju\u010deni na ruter koji podr\u017eava funkciju Multi-WAN. To mo\u017ee biti OpenWRT sa paketom mwan3, mikrotik, ubiquiti ili bilo koji drugi potro\u0161a\u010dki ruter, s obzirom na to da takva opcija vi\u0161e nije retkost.<\/p>\n

Za modeliranje situacije, pretpostavimo da su provajderi dodelili ovakve adrese:<\/p>\n

WAN1 \u2014 11.11.11.11\nWAN2 \u2014 22.22.22.22\nWAN3 \u2014 33.33.33.33\n<\/code><\/pre>\n
\nDakle, povezuju\u0107i se na udaljeni server example.com<\/b> Vsak od ponudnikov bo oddaljeni stre\u017enik videl tri neodvisne IP naslove stranke. Obvladovanje prometa omogo\u010da razdelitev obremenitve med kanali in hkratno uporabo vseh treh. Za enostavnost si predstavljajmo, da obremenitev delimo enakomerno med vse kanale. Tako, ko stranka odpre spletno mesto z recimo tremi slikami, vsako sliko nalo\u017ei preko lo\u010denega ponudnika. Na strani spletnega mesta to izgleda kot povezave s treh razli\u010dnih IP-jev.<\/p>\n
\"Pravi
\nPri obvladovanju prometa na ravni povezav vsak TCP povezava poteka skozi lo\u010denega ponudnika.<\/p>\n
Tak na\u010din obvladovanja pogosto prina\u0161a te\u017eave za uporabnike. Na primer, mnoge spletne strani strogo povezujejo pi\u0161kotke in \u017eetone z IP naslovom stranke, in \u010de se ta nepri\u010dakovano spremeni, se zahteva zavrne ali pa uporabnika odjavimo s spletnega mesta. To se pogosto dogaja v sistemih internetnega ban\u010dni\u0161tva in drugih spletnih mestih s strogimi pravili uporabni\u0161kih sej. Tukaj je en preprost prikaz: glasbeni datoteki na VK.com sta dostopni le ob veljavni se\u0161ni klju\u010de, ki je povezan z IP, in stranke, ki uporabljajo to obvladovanje, pogosto ne morejo predvajati avdio posnetkov, ker je zahteva \u0161la ne skozi tistega ponudnika, s katerim je povezana seja.<\/p>\n
\"Pravi
\nPri prenosu torrentov obvladovanje prometa na ravni povezav se\u0161teje pasovno \u0161irino vseh kanalov.<\/p>\n
Tak\u0161no obvladovanje omogo\u010da se\u0161tevanje hitrosti internetnega kanala pri uporabi ve\u010d povezav. Na primer, \u010de ima vsak od treh ponudnikov hitrost 100 Megabitov, bomo pri prenosu torrentov prejeli 300 Megabitov. Zato, ker torrent odpre ve\u010d povezav, ki se razdelijo med vse ponudnike in na koncu izkoristijo vse kanale.<\/p>\n
Pomembno je razumeti, da bo ena sama TCP povezava vedno \u0161la le skozi enega ponudnika. To pomeni, da \u010de prenosimo en velik datotek po HTTP, bo ta povezava vzpostavljena preko enega od ponudnikov, in \u010de se povezava s tem ponudnikom prekine, se bo tudi prenos prekinil. <\/p>\n
\"Pravi
\nEna povezava vedno uporablja le en internetni kanal.<\/p>\n
To je prav tako veljavno za video prenose. \u010ce prena\u0161ate video na nekem hipoteti\u010dnem Twitchu, neuravnote\u017eenost na ravni IP povezav ne bo prinesla nobene posebne koristi, saj se bo video prenos pretakal znotraj enega IP povezovanja. V tem primeru, \u010de pride do te\u017eav z povezljivostjo pri WAN ponudniku, na primer izgube paketov ali zmanj\u0161anja hitrosti, ne boste mogli takoj preklopiti na drugega ponudnika. Prenos boste morali ustaviti in se ponovno povezati. <\/p>\n
U\u010dinkovito zdru\u017eevanje kanalov<\/h2>\n
\nPravo zdru\u017eevanje kanalov omogo\u010da, da se eno povezavo do hipoteti\u010dnega Twicha takoj usmeri skozi vse ponudnike, tako da, \u010de katerikoli od ponudnikov odpove, povezava ne bo prekinjena. To je presenetljivo zapletena naloga, ki \u0161e vedno nima optimalne re\u0161itve. Mnogi niti ne vedo, da je to mogo\u010de! <\/p>\n
Iz prej\u0161njih ilustracij se spomnimo, da hipoteti\u010dni stre\u017enik Twitch lahko sprejme na\u0161 video tok le od enega izvornega IP naslova, kar pomeni, da mora biti ta vedno stalna, ne glede na to, kateri ponudniki so odpovedali, in kateri delujejo. Za dosego tega bomo potrebovali zdru\u017eevalni stre\u017enik, ki bo zaklju\u010dil vse na\u0161e povezave in jih zdru\u017eil v eno.<\/p>\n
\"Pravi
\nZdru\u017eevalni stre\u017enik aglomerira vse kanale v en tunel. Vse povezave potekajo z naslova zdru\u017eevalnega stre\u017enika.<\/p>\n
V tak\u0161ni shemi se uporabljajo vsi ponudniki, in izklop katerega koli izmed njih ne bo povzro\u010dil prekinitev povezave s stre\u017enikom Twitch. V bistvu gre za poseben VPN tunel, pod pokrovom katerega je ve\u010d internetnih kanalov. Glavna naloga tak\u0161ne sheme je pridobiti \u010dim bolj kakovostno povezavo. \u010ce pride do te\u017eav na enem izmed ponudnikov, izgube paketov ali pove\u010dane latence, to ne sme vplivati na kakovost povezave, saj se bo obremenitev avtomatsko porazdelila po drugih, bolj kakovostnih kanalih, ki so na voljo. <\/p>\n
Komercialne re\u0161itve<\/h3>\n
\nTo te\u017eavo \u017ee dolgo skrbi tiste, ki prena\u0161ajo dogodke v \u017eivo in nimajo dostopa do kakovostnega interneta. Za take naloge obstaja ve\u010d komercialnih re\u0161itev, na primer podjetje Teradek izdeluje tak\u0161ne monstruozne usmerjevalnike, v katere se vstavljajo \u0161katle USB modemov:<\/p>\n
\"Pravi
\nUsmerjevalnik za video prenose z mo\u017enostjo agregacije kanalov<\/p>\n
Tak\u0161na naprava obi\u010dajno vklju\u010duje mo\u017enost zajema video signala preko HDMI ali SDI. Skupaj z usmerjevalnikom se proda naro\u010dnina na storitev agregacije kanalov ter obdelave videoprena\u0161anja, njegovo prekodiranje in ponovno prena\u0161anje. Cena tak\u0161nih naprav se za\u010dne pri 2000 $ s kompleti modemov, poleg tega je treba pla\u010dati \u0161e naro\u010dnino na storitev. <\/p>\n
V\u010dasih to izgleda dovolj zastra\u0161ujo\u010de:<\/p>\n
\"Pravi
\n<\/p>\n
Nastavljamo OpenMPTCPRouter<\/h2>\n
\nProtokol MP-TCP<\/a><\/noindex> (MultiPath TCP) je bil zasnovan za mo\u017enost povezovanja preko ve\u010d kanalov hkrati. Na primer, ga<\/a><\/noindex> podpira iOS<\/p>\n
in lahko hkrati pove\u017ee z oddaljenim stre\u017enikom preko WiFi in prek mobilne mre\u017ee. Pomembno je razumeti, da to nista dve lo\u010deni TCP povezavi, temve\u010d ena sama povezava, vzpostavljena hkrati preko dveh kanalov. Da to deluje, mora tudi oddaljeni stre\u017enik podpirati MPTCP.<\/a><\/noindex> OpenMPTCPRouter<\/p>\n
\"Pravi
\nje odprt projekt programske usmerjevalne naprave, ki dejansko omogo\u010da agregacijo kanalov. Avtorji trdijo, da je projekt v alfa razli\u010dici, a ga je mo\u017eno \u017ee uporabljati. Sestavljen je iz dveh delov \u2014 agregacijskega stre\u017enika, ki je lociran na internetu, in usmerjevalnika, na katerega se povezuje ve\u010d internetnih ponudnikov in same odjemalske naprave: ra\u010dunalniki, telefoni. Kot uporabni\u0161ki usmerjevalnik lahko deluje Raspberry Pi, nekateri WiFi usmerjevalniki ali navaden ra\u010dunalnik. Na voljo so \u017ee pripravljene zbirke za razli\u010dne platforme, kar je zelo priro\u010dno.<\/p>\n
Na\u010delo delovanja OpenMPTCPRouter<\/h2>\n
\nNastavitev agregacijskega stre\u017enika <\/p>\n
Agregacijski stre\u017enik je lociran na internetu in kon\u010duje povezave iz vseh kanalov odjemalskega usmerjevalnika v eno. IP naslov tega stre\u017enika bo zunanji naslov pri dostopu do interneta preko OpenMPTCPRouter.<\/p>\n
Za to nalogo bomo uporabili VPS stre\u017enik na Debian 10.<\/p>\n