Ці можна аб'яднаць некалькі інтэрнэт-каналаў у адзін? Вакол гэтай тэмы куча памылак і міфаў, нават сеткавыя інжынеры з досведам часта не ведаюць пра тое, што гэта магчыма. У большасці выпадкаў, аб'яднаннем каналаў памылкова завуць балансаванне на ўзроўні NAT ці failover. Але сапраўднае падсумоўванне дазваляе пусціць адно адзінае TCP-падлучэнне адначасова па ўсіх інтэрнэт-каналах, напрыклад відэатрансляцыю так, каб пры абрыве любога з інтэрнэт-каналаў вяшчанне не спынялася.
Існуюць дарагія камерцыйныя рашэнні для відэатрансляцый, але такія прылады каштуюць шмат кілабаксаў. У артыкуле апісваецца настройка бясплатнага, адкрытага пакета OpenMPTCPRouter, разбіраюцца папулярныя міфы аб падсумоўванні каналаў.
Міфы пра сумаванне каналаў
Ёсць шмат бытавых роўтэраў, якія падтрымліваюць функцыю Multi-WAN. Часам вытворцы называюць гэта сумаванне каналаў, што не зусім дакладна. Многія сецявікі вераць, што акрамя і суміравання на L2 узроўні, ніякага іншага аб'яднання каналаў не існуе. Мне часта даводзілася чуць, што гэта ўвогуле немагчыма ад людзей, якія працуюць у тэлекомах. Таму паспрабуем разабрацца ў папулярных міфах.
Балансіроўка на ўзроўні IP-падлучэнняў
Гэта самы даступны і папулярны спосаб утылізаваць некалькі інтэрнэт-каналаў адначасова. Для прастаты ўявім, што ў вас ёсць тры інтэрнэт правайдэра, кожны выдае вам рэальны IP-адрас са сваёй сеткі. Усе гэтыя правайдэры падлучаныя ў роўтэр з падтрымкай функцыі Multi-WAN. Гэта можа быць OpenWRT з пакетам mwan3, mikrotik, ubiquiti або любы іншы бытавы роўтэр, балазе цяпер такая опцыя ўжо не рэдкасць.
Для мадэлявання сітуацыі ўявім, што правайдэры выдалі нам такія адрасы:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33
Гэта значыць, падлучаючыся да выдаленага сервера example.com праз кожнага з правайдэраў, выдалены сервер будзе бачыць тры незалежных source ip кліента. Балансіроўка дазваляе падзяліць нагрузку па каналах і выкарыстоўваць іх усе тры адначасова. Для прастаты ўявім, што мы дзелім нагрузку паміж усімі каналамі пароўну. У выніку, калі кліент адкрывае сайт, на якім умоўна тры карцінкі, ён загружае кожны малюнак праз асобнага правайдэра. На баку сайта гэта выглядае як падлучэнне з трох розных IP.
Пры балансаванні на ўзроўні падлучэнняў, кожнае TCP-падлучэнне ідзе праз асобнага правайдэра.
Такі рэжым балансавання часта нясе праблемы для карыстальнікаў. Напрыклад, шматлікія сайты цвёрда прывязваюць cookie і токены да IP-адрасу кліента, і калі ён раптам змяніўся, то запыт адкідаецца ці кліента разлагінвае на сайце. Гэта часта прайграваецца ў сістэмах кліент-банка і на іншых сайтах са строгімі правіламі карыстацкіх сесій. Вось просты наглядны прыклад: музычныя файлы ў VK.com даступныя толькі пры сапраўдным ключы сесіі, які прывязаны да IP, і ў кліентаў, якія выкарыстоўваюць такое балансаванне, часта не прайграваюцца аўдыё, таму што запыт сышоў не праз таго правайдэра, да якога прывязана сесія.
Пры загрузцы торэнтаў балансаванне на ўзроўні падлучэнняў сумуе прапускную здольнасць усіх каналаў
Такое балансаванне дазваляе атрымаць падсумоўванне хуткасці інтэрнэт-канала, пры выкарыстанні мноства падлучэнняў. Напрыклад, калі ў кожнага з трох правайдэраў хуткасць 100 мегабіт, то пры загрузцы торэнтаў мы атрымаем 300 мегабіт. Таму што торэнт адчыняе мноства падлучэнняў, якія размяркоўваюцца паміж усімі правайдэрамі і ў выніку ўтылізуюць увесь канал.
Важна разумець, што адно адзінае TCP-падлучэнне заўсёды пройдзе толькі праз аднаго правайдэра. Гэта значыць калі мы спампоўваем адзін вялікі файл па HTTP, тое гэтае падлучэнне будзе выканана праз аднаго з правайдэраў, і калі сувязь з гэтым правайдэрам абарвецца, то загрузка таксама зламаецца.
Адно падлучэнне заўсёды будзе выкарыстоўваць толькі адзін інтэрнэт-канал
Гэта справядліва і для відэатрансляцый. Калі вы вяшчаеце струменевае відэа на нейкі ўмоўны Twitch, то балансаванне на ўзроўні IP-падлучэнняў не дасць ніякай асаблівай карысці, бо відэа-струмень будзе транслявацца ўсярэдзіне аднаго IP-падлучэнні. У дадзеным выпадку, калі ў правайдэра WAN 3 пачнуцца праблемы са сувяззю, напрыклад страты пакетаў ці зніжэнне хуткасці, тыя вы не зможаце маментальна пераключыцца на іншага правайдэра. Трансляцыю давядзецца спыняць і перападключаць нанава.
Сапраўднае сумаванне каналаў
Рэальнае сумаванне каналаў дае магчымасць пусціць адно падлучэнне да ўмоўнага Twitch адразу праз усіх правайдэраў такім чынам, што калі любы з правайдэраў зламаецца, падлучэнне не абарвецца. Гэта на здзіўленне складаная задача, якая да гэтага часу не мае аптымальнага рашэння. Многія нават не ведаюць, што такое магчыма!
Па папярэдніх ілюстрацыях мы памятаем, што ўмоўны сервер Twitch можа прыняць ад нас відэаструмень толькі ад аднаго source IP адрасы, значыць ён павінен быць у нас заўсёды сталым, па-за залежнасцю ад таго, якія правайдэры ў нас адваліліся, а якія працуюць. Каб гэтага дамагчыся, нам запатрабуецца які падсумоўвае сервер, які будзе тэрмінаваць усе нашы падлучэнні і аб'ядноўваць іх у адно.
Сумуючы сервер агрэгуе ўсе каналы ў адзін тунэль. Усе падлучэнні адбываюцца з адрасу падсумоўваючага сервера
У такой схеме выкарыстоўваюцца ўсе правайдэры, і адключэнне любога з іх не выкліча абрыў сувязі з серверам Twitch. Па сутнасці, гэта асаблівы VPN-тунэль, пад капотам у якога адразу некалькі інтэрнэт-каналаў. Галоўная задача такой схемы - атрымаць максімальна якасны канал сувязі. Калі на адным з правайдэраў пачаліся праблемы, страта пакетаў, павелічэнне затрымак, тое гэта не павінна ніяк адбіцца на якасці сувязі, бо нагрузка аўтаматычна будзе размяркоўвацца па іншых, больш якасных каналах, якія ёсць у распараджэнні.
Камерцыйныя рашэнні
Гэта праблема даўно непакоіць тых, хто вядзе прамыя трансляцыі мерапрыемстваў і не мае доступу да якаснага інтэрнета. Для такіх задач існуюць некалькі камерцыйных рашэнняў, напрыклад кампанія Teradek робіць такія монструозныя роўтэры, у якія ўстаўляюцца пачкі USB мадэмаў.
Роўтар для відэатрансляцый з функцыяй падсумоўвання каналаў
У такіх прыладах, звычайна, убудаваная магчымасць захопу відэасігналу па HDMI ці SDI. Разам з роўтэрам прадаецца падпіска на сэрвіс падсумоўвання каналаў, а таксама апрацоўкі відэаструменю, перакадаванні яго і рэтрансляцыі далей. Кошт такіх прылад пачынаецца ад 2к$ з камплектам мадэмаў, плюс асобна падпіска на сэрвіс.
Часам гэта выглядае досыць жахліва:
Наладжваем OpenMPTCPRouter
пратакол (MultiPath TCP) прыдуманы для магчымасці падлучэння адразу па некалькіх каналах. Напрыклад, яго і можа адначасова падлучаць да выдаленага сервера па WiFi і праз сотавую сетку. Важна разумець, што гэта не два асобныя TCP-падлучэнні, а менавіта адно падлучэнне, усталяванае адразу па двух каналах. Каб гэта працавала, выдалены сервер павінен падтрымліваць MPTCP таксама.
- Гэта адкрыты праект праграмнага роўтара, які дазваляе па-сапраўднаму сумаваць каналы. Аўтары заяўляюць, што праект знаходзіцца ў статуце альфа-версіі, але ім ужо можна карыстацца. Ён складаецца з двух частак - падсумоўваючага сервера, які размяшчаецца ў інтэрнэце і роўтара, да якога падключаюцца некалькі інтэрнэт-правайдэраў і самі кліенцкія прылады: кампутары, тэлефоны. У якасці карыстацкага роўтара можа выступаць Raspberry Pi, некаторыя WiFi-роўтары ці звычайны кампутар. Ёсць гатовыя зборкі пад розныя платформы, што вельмі зручна.
Прынцып працы OpenMPTCPRouter
Настройка падсумоўваючага сервера
Які падсумоўвае сервер размяшчаецца ў інтэрнэце і тэрмінуе падлучэнні са ўсіх каналаў кліенцкага роўтара ў адно. IP-адрас гэтага сервера будзе вонкавым адрасам пры выхадзе ў інтэрнэт праз OpenMPTCPRouter.
Для гэтай задачы будзем выкарыстоўваць VPS-сервер на Debian 10.
Патрабаванні да падсумоўваючага сервера:
- MPTCP не працуе на віртуалізацыі OpenVZ
- Павінна быць магчымасць усталёўкі ўласнага ядра Linux
Сервер разгортваецца выкананнем адной каманды. Скрыпт усталюе ядро з падтрымкай mptcp і ўсе неабходныя пакеты. Даступныя ўсталявальныя скрыпты для Ubuntu і Debian.
wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh
Вынік паспяховай усталёўкі сервера.
Захоўваем паролі, яны спатрэбяцца нам для настройкі кліенцкага роўтара, і перазагружаемся. Важна мець у выглядзе, што пасля ўсталёўкі SSH будзе даступны на порце 65222. Пасля перазагрузкі трэба пераканацца, што мы загрузіліся з новым ядром
uname -a
Linux test-server.local 4.19.67-mptcp
Бачым побач з нумарам версіі надпіс mptcp, значыць ядро ўсталявалася карэктна.
Настройка кліенцкага роўтара
На даступныя гатовыя зборкі для некаторых платформаў, напрыклад Raspberry Pi, Banana Pi, роўтэры Lynksys і віртуальныя машыны.
Гэтая частка openmptcprouter заснавана на OpenWRT, у якасці інтэрфейсу выкарыстоўваецца LuCI, знаёмы ўсім, хто калі-небудзь сутыкаўся з OpenWRT. Дыстрыбутыў важыць каля 50Мб!
У якасці тэставага стэнда я буду выкарыстоўваць Raspberry Pi і некалькі USB-мадэмаў з рознымі аператарамі: МТС і Мегафон. Як запісаць выяву на SD-карту, мяркую, не трэба распавядаць.
Першапачаткова Ethernet-порт у Raspberry Pi наладжаны як lan са статычным IP-адрасам 192.168.100.1. Каб не важдацца з правадамі на стале, я падлучыў Raspberry Pi да WiFi кропцы доступу і задаў на WiFi-адаптары кампутара статычны адрас 192.168.100.2. DHCP-сервер па змаўчанні не ўключаны, таму трэба выкарыстоўваць статычныя адрасы.
Цяпер можна зайсці ў вэб-інтэрфейс
Пры першым уваходзе сістэма папросіць задаць пароль root, з гэтым жа паролем будзе даступны SSH.
У наладах LAN можна задаць патрэбную падсетку і ўключыць DHCP-сервер.
Я выкарыстоўваю мадэмы, якія вызначаюцца як USB Ethernet інтэрфейсы з асобным DHCP-серверам, таму гэта запатрабавала ўстаноўкі . Працэдура ідэнтычная наладзе мадэмаў у звычайным OpenWRT, таму я не буду разглядаць яе тут.
Далей трэба наладзіць WAN-інтэрфейсы. Першапачаткова ў сістэме створаны два віртуальныя інтэрфейсы WAN1 і WAN2. Ім трэба прызначыць фізічную прыладу, у маім выпадку гэта імёны інтэрфейсаў USB-мадэмаў.
Каб не заблытацца ў імёнах інтэрфейсаў, я раю глядзець паведамленні dmesg, падлучыўшыся па SSH.
Так як мае мадэмы самі выступаюць роўтэрамі, і самі маюць DHCP-сервер, мне прыйшлося змяніць налады іх унутраных дыяпазонаў сетак і адключыць DHCP-сервер, таму што першапачаткова абодва мадэма выдаюць адрасы з адной сеткі, а гэта выклікае канфлікт.
OpenMPTCPRouter патрабуе, каб адрасы WAN-інтэрфейсаў былі статычнымі, таму прыдумляем мадэмам падсеткі і наладжваем у меню system → openmptcprouter → interface settings. Тутака ж трэба паказаць IP-адрас і ключ сервера, атрыманы на этапе ўсталёўкі падсумоўваючага сервера.
У выпадку ўдалай настройкі, на старонцы статусу павінна з'явіцца падобная карціна. Відаць, што роўтэр змог дастукацца да падсумоўваючага сервера і абодва канала працуюць штатна.
Па змаўчанні выкарыстоўваецца рэжым shadowsocks + mptcp. Гэта такі проксі, які заварочвае ў сябе ўсе падключэнні. Першапачаткова ён настроены апрацоўваць толькі TCP, але можна ўключыць і UDP.
Калі на старонцы статусу няма памылак, на гэтым настройку можна лічыць скончанай.
З некаторымі правайдэрамі можа ўзнікнуць сітуацыя, калі на шляху руху трафіку сцяг mptcp абразаецца, тады будзе такая памылка:
У гэтым выпадку можна выкарыстоўваць іншы рэжым працы, без выкарыстання MPTCP, падрабязней пра гэта .
Заключэнне
Праект OpenMPTCPRouter вельмі цікавы і важны, бо гэта, мабыць, адзінае адчыненае комплекснае рашэнне праблемы падсумоўвання каналаў. Усё астатняе альбо наглуха зачыненае і прапрыетарнае, альбо проста асобныя модулі, разабрацца з якімі звычайнаму чалавеку не пад сілу. На бягучым этапе развіцця праект яшчэ дастаткова сырой, вельмі бедная дакументацыя, многія рэчы проста не апісаны. Але пры гэтым ён усё ж працуе. Спадзяюся, што ён будзе і далей развівацца, і мы атрымаем бытавыя роўтэры, якія будуць умець нармальна аб'ядноўваць каналы са скрынкі.
Падпісвайцеся на нашага распрацоўніка ў Instagram
Крыніца: habr.com