Възможно ли е да се обединят няколко интернет канала в един? Около тази тема има много заблуждения и митове, дори опитни мрежови инженери често не знаят, че това е възможно. В повечето случаи, обединението на канали погрешно се нарича балансировка на ниво 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
WAN3 — 33.33.33.33
Тоест, свързвайки се с отдалечен сървър example.com Чрез все доставчици отдаления, сървърът ще вижда три независими клиентски IP адреса. Балансирането позволява разпределяне на натоварването през каналите и използването им заедно. За опростяване ще приемем, че разпределяме натоварването между всички канали равномерно. В резултат, когато клиентът отваря сайт с три снимки условно, той зарежда всяка снимка през отделен доставчик. От страната на сайта това изглежда като свързвания от три различни IP адреса.
При балансиране на ниво свързвания, всяко TCP свързване преминава през отделен доставчик.
Такава режим на балансиране често носи проблеми за потребителите. Например, много сайтове строго свързват бисквитки и токени с IP адреса на клиента, и ако той внезапно се промени, заявката се отхвърля или клиентът се изключва от сайта. Това често се среща в системите за онлайн банкиране и на други сайтове с строги правила за потребителските сесии. Ето един прост пример: музикалните файлове в VK.com са достъпни само при валиден сесионен ключ, който е свързан с IP адреса, и при клиенти, използващи такова балансиране, често не се възпроизвежда аудио, защото заявката е изпратена не през онзи доставчик, с който е свързана сесията.
При изтегляне на торенти, балансирането на ниво свързвания сумира пропускателната способеност на всички канали.
Такова балансиране позволява получаване на сумата от скоростта на интернет канала при използване на множество свързвания. Например, ако всеки от трите доставчици има скорост 100 Мегабита, при изтегляне на торенти ще получим 300 Мегабита. Защото торентът отваря множество свързвания, които се разпределят между всички доставчици и в крайна сметка усвояват целия канал.
Важно е да се разбере, че едно единствено TCP свързване винаги ще премине само през един доставчик. Тоест, ако сваляме един голям файл по HTTP, това свързване ще бъде извършено през един от доставчиците и ако връзката с този доставчик бъде прекъсната, свалянето също ще се прекъсне.
Едно свързване винаги ще използва само един интернет канал.
Това важи и за видео предавания. Ако предавате поточно видео на някакъв условен Twitch, то балансирането на ниво IP връзки няма да донесе никаква особена полза, тъй като видео потока ще се предава в рамките на една IP връзка. В такъв случай, ако на доставчика на WAN 3 възникнат проблеми с връзката, например загуба на пакети или намалена скорост, то вие няма да можете мигновено да превключите на друг доставчик. Предаването ще трябва да спре и да се свържете отново.
Настоящо обобщаване на канали
Реалното обобщаване на канали позволява да се пусне едно свързване към условния Twitch през всички доставчици, така че, ако който и да е от доставчиците се провали, връзката няма да прекъсне. Това е изненадващо сложна задача, която все още няма оптимално решение. Мнозина дори не знаят, че това е възможно!
По предишните илюстрации помним, че условният сървър Twitch може да приеме от нас видео поток само от един source IP адрес, следователно той трябва да бъде постоянен, независимо от това, кои доставчици са отпаднали и кои работят. За да постигнем това, ще ни е необходим обобщаващ сървър, който ще терминализира всички наши връзки и ще ги обедини в едно.
Обобщаващият сървър агрегира всички канали в един тунел. Всички връзки се осъществяват от адреса на обобщаващия сървър
В такава схема се използват всички доставчици, а изключването на който и да е от тях няма да предизвика прекъсване на връзката със сървъра Twitch. По същество, това е специален VPN тунел, под капака на който стоят няколко интернет канала. Основната задача на такава схема е да се получи максимално качествена връзка. Ако на един от доставчиците започнат проблеми, загуба на пакети, увеличаване на закъсненията, то това не трябва да се отразява на качеството на връзката, тъй като натоварването автоматично ще се разпределя по другите, по-качествени канали, които са на разположение.
Комерсиални решения
Този проблем отдавна тревожи тези, които водят директни предавания на събития и нямат достъп до качествен интернет. За такива задачи съществуват няколко комерсиални решения, например компанията Teradek произвежда такива монструозни рутери, в които се поставят пачки USB модеми:
Рутер за видеопотокове с функция за агрегация на канали
В тези устройства обикновено е вградена възможност за захващане на видео сигнал чрез HDMI или SDI. Заедно с рутера се предлага абонамент за услугата за агрегация на канали, както и за обработка на видеопотока, неговото транскодиране и повторно излъчване. Цената на тези устройства започва от 2000 $ с комплект модеми, плюс отделен абонамент за услугата.
Понякога това изглежда достатъчно плашещо:
Настройка на 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. Дистрибутивът е с размер около 50MB!
Като тестова платформа ще използвам 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
