Възможно ли е да се обединят няколко интернет канала в един? Около тази тема има много неразбирания и митове, дори мрежови инженери с опит често не знаят, че това е възможно. В повечето случаи, обединение на каналите погрешно се нарича балансировка на ниво 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 доставчикът има проблеми с връзката, например загуба на пакети или забавяне на скоростта, няма да можете моментално да преминете на друг доставчик. Излъчването ще трябва да спре и да се свържете отново.
Настояща агрегация на канали
Истинската агрегация на канали позволява да се установи едно свързване към условен 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
Сървърът се разгръща с изпълнението на една команда. Скриптът ще инсталира ядрo с поддръжка на 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
