Чи можна поєднати кілька інтернет-каналів в один? Навколо цієї теми купа помилок і міфів, навіть мережеві інженери з досвідом часто не знають, що це можливо. У більшості випадків об'єднання каналів помилково називають балансування на рівні 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
Налаштування підсумовуючого сервера
Підсумовуючий сервер знаходиться в інтернеті і термінує підключення з усіх каналів клієнтського роутера в одне. ІР-адреса цього сервера буде зовнішньою адресою при виході в інтернет через 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