Multipath TCP (MPTCP) та VPN Roaming: безшовне перемикання між Wi-Fi та 5G

Мобільне мережеве середовище відзначається безперервною динамікою фізичних каналів. Пересуваючись між офісами, громадським транспортом та житловими кварталами, користувачі смартфонів і ноутбуків постійно перемикаються між локальними точками Wi-Fi та стільниковими вишками 5G. У стандартному мережевому стеку таке вертикальне перемикання (vertical handover) регулярно призводить до розриву активних з'єднань, обриву голосових викликів, втрати сесій SSH та переривання передачі файлів.

Для подолання цієї проблеми було створено два відмінні технологічні підходи: протокол Multipath TCP (MPTCP, стандартизований у RFC 8684) та архітектура мобільного роумінгу сучасних VPN мережевого рівня (Layer 3). Тоді як MPTCP координує кілька підпотоків безпосередньо на транспортному рівні, новітні VPN (на основі WireGuard та рушія RiceGuard у VPNRice) вирішують завдання на мережевому рівні за допомогою криптографічного відстеження кінцевих точок без збереження стану. Зіставлення їхньої інженерної будови, практичних перешкод та стійкості до мережевих шлюзів (middlebox) пояснює, чому тунелювання Layer 3 залишається надійним вибором для мобільних користувачів.

Реалії мобільних мереж: чому зникає зв'язок під час хендоверу

Класичний інтернет-зв'язок базується на жорсткій фіксації 4-елементного кортежу протоколу TCP:

        [ Вихідна IP-адреса ]  :  [ Вихідний порт ]
                                ↕
        [ Цільова IP-адреса ]  :  [ Цільовий порт ]

Коли смартфон відключається від офісного Wi-Fi (192.168.1.45, трансльованого через NAT у публічну IP 203.0.113.10) і переходить на передачу даних через 5G (198.51.100.82), адреса пристрою змінюється миттєво. Для віддаленого сервера нові пакети надходять від невідомого і неавторизованого джерела.

Оскільки класичний TCP не може переприв'язати відкритий сокет на іншу IP-адресу без розриву сесії:

Віддалений сервер продовжує надсилати пакети підтвердження на стару IP-адресу Wi-Fi.
Операційна система клієнта не отримує очікуваних даних, що активує таймери повторного надсилання TCP.
Зрештою з'єднання скидається за тайм-аутом, змушуючи програми (SSH, потокове аудіо, веб-сокети) наново проходити тристороннє рукостискання (SYN → SYN-ACK → ACK), погоджувати криптографічні ключі TLS та повторно авторизуватися.

Механіка Multipath TCP (MPTCP): керування підпотоками

Протокол MPTCP (RFC 8684) усуває проблему розриву сокетів, відокремлюючи прикладний потік даних від конкретних фізичних інтерфейсів:

┌─────────────────────────────────────────────────────────────┐
│                      Прикладний рівень                      │
│                  (Стандартні сокети Posix)                  │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│                    Multipath TCP (MPTCP)                    │
│      Генерація токенів, координація підпотоків, збирання    │
└──────────────┬──────────────────────────────┬───────────────┘
               │                              │
┌──────────────▼──────────────┐┌──────────────▼───────────────┐
│     Підпотік TCP 1 (Wi-Fi)  ││       Підпотік TCP 2 (5G)    │
│  Вих: 192.168.1.45 (wlan0)  ││    Вих: 10.42.0.12 (модем)   │
└─────────────────────────────┘└──────────────────────────────┘

Замість фіксації на єдиній IP-адресі, MPTCP надає програмі єдиний сокет, паралельно відкриваючи незалежні підпотоки TCP через усі доступні мережеві карти.

Встановлення зв'язку з опцією MP_CAPABLE: Під час створення підключення клієнт додає поле MP_CAPABLE у пакет SYN. Якщо сервер підтримує MPTCP, він надсилає підтвердження, обмінюючись 64-бітними токенами безпеки.
Підключення нових шляхів через MP_JOIN: Коли стає доступним додатковий інтерфейс (наприклад, з'єднання 5G), клієнт відправляє пакет MP_JOIN через нову мережу, вказуючи токен початкової сесії.
Непомітний перерозподіл трафіку: Якщо сигнал Wi-Fi згасає, MPTCP перемикає передачу пакетів на канал 5G. Послідовність байтів узгоджується на рівні головного з'єднання (Data Sequence Signal - DSS), дозволяючи приймати потік без збоїв у роботі додатків.

Проблема мережевих бар'єрів: чому MPTCP важко масштабувати

Попри технічну довершеність, використання MPTCP у глобальній мережі наражається на серйозні бар'єри з боку проміжних пристроїв (middlebox):

[ Клієнт MPTCP ] ──► [ Корпоративний фаєрвол / CGNAT ] ──► [ Веб-сервер ]
                      (Аналіз опції TCP Option 30)
                      ├── Видалення невідомих опцій ───► (Відкат до звичайного TCP)
                      ├── Зміна номерів Sequence ──────► (Помилка контрольної суми)
                      └── Блокування нестандартних дій ─► (Повний розрив зв'язку)

Вирізання опцій TCP фаєрволами: Комерційні міжмережеві екрани, операторські шлюзи CGNAT та системи глибокого аналізу пакетів (DPI) часто видаляють невідомі поля з заголовків TCP. Оскільки MPTCP повністю залежить від опції TCP Option 30, її видалення непомітно переводить підключення у звичайний одноканальний режим.
Вимога підтримки на обох кінцях: MPTCP працює виключно за умови, що і пристрій користувача, і сервер призначення мають активовану підтримку MPTCP у ядрі. Переважна більшість сайтів та хмарних сервісів використовують звичайні ядра ОС без увімкненого MPTCP.
Модифікація порядкових номерів: Проміжні маршрутизатори нерідко переписують номери TCP Sequence для захисту від SYN-атак. Це руйнує внутрішнє зіставлення блоків даних (Data Sequence Mapping) у MPTCP, спричиняючи аварійне відключення підпотоків.

Мобільний роумінг у сучасних VPN: технологія WireGuard та RiceGuard

Сучасні протоколи VPN мережевого рівня забезпечують надійний хендовер без втручання у сокети додатків і без залежності від заголовків TCP. WireGuard (і технологія RiceGuard у VPNRice) базуються на принципі криптографічного роумінгу кінцевих точок без збереження стану (Stateless Cryptographic Endpoint Roaming):

[ Мобільний клієнт ]                                [ Шлюз VPN (RiceGuard) ]
         │                                                      │
         ├────── (UDP-пакет через Wi-Fi: 192.168.1.45) ────────►│
         │       Автентифікація ключем Curve25519 32 байти      │ (Запис: Peer -> 192.168.1.45)
         │                                                      │
   [ Зникнення Wi-Fi ]                                          │
   [ Перехід на 5G ]                                            │
         │                                                      │
         ├────── (UDP-пакет через 5G: 198.51.100.82) ──────────►│
         │       Підписаний валідним сесійним ключем            │ (Ядро миттєво оновлює:
         │                                                      │  Peer -> 198.51.100.82)
         │◄───── (Відповідний UDP-пакет летить на 198.51.100.82)─┤

У такій структурі всі програми взаємодіють лише з віртуальним мережевим адаптером (наприклад, tun0 чи wg0), закріпленим за незмінною внутрішньою адресою (наприклад, 10.8.0.2):

Стабільність сокетів додатків: Оскільки прикладне програмне забезпечення працює через статичний віртуальний інтерфейс, його сокети не відчувають фізичної зміни IP-адреси. Сесія SSH чи голосовий зв'язок залишаються активними без найменших затримок.
Автоматичне симетричне оновлення UDP: Під час перемикання з Wi-Fi на 5G клієнт надсилає наступний зашифрований пакет UDP через стільникову мережу. Шлюз розшифровує пакет та перевіряє криптографічний підпис. Якщо пакет валідний для 32-байтного відкритого ключа клієнта, ядро сервера негайно оновлює цільову адресу й порт у таблиці маршрутизації.
Перемикання без затримок: Оновлення маршруту в ядрі ОС здійснюється за частки мікросекунди, не вимагаючи повторного шифрувального рукостискання чи обміну новими ключами.

Особливості об'єднання каналів: затримки, джитер та буферблоат

Окрім послідовного перемикання мереж, у спеціальних завданнях реалізують одночасне об'єднання каналів (передачу даних паралельно через Wi-Fi та 5G). Робота з кількома середовищами одночасно створює специфічні виклики:

Порушення черговості пакетів (Packet Reordering): Канали Wi-Fi та 5G мають суттєво різний пінг. Якщо надіслати пакет 1 через Wi-Fi (затримка 15 мс), а пакет 2 — через 5G (затримка 45 мс), пакет 1 прибуде значно раніше. За відсутності інтелектуального відновлення черги стек TCP сприйме це як втрату даних і різко зменшить пропускну здатність.
Ефект роздування буферів (Bufferbloat): Мобільні мережі використовують об'ємні черги буферизації для згладжування коливань сигналу. При сумісній роботі інтерфейсів ці буфери породжують стрибки затримки, гальмуючи чутливий інтерактивний трафік.
Рішення у VPN Layer 3: Протокол RiceGuard вирішує це завдання за допомогою постійного моніторингу каналів. Відстежуючи затримку та відсоток втрат, тунель направляє чутливі дані (команди SSH, запити DNS, голос) маршрутом із найменшою затримкою, спрямовуючи важкий трафік на додатковий лінк або тримаючи його напоготові для резерву.

Порівняльна таблиця: MPTCP проти VPN Roaming Layer 3

Критерій оцінки	Multipath TCP (MPTCP)	VPN Roaming Layer 3 (RiceGuard)
Рівень моделі OSI	Layer 4 (Транспортний / TCP Option 30)	Layer 3 (Мережевий / IP в UDP)
Охоплення протоколів	Лише потік TCP (Не захищає UDP, ICMP)	Універсально (Захищає TCP, UDP, ICMP)
Вимоги до сервера	Підтримка MPTCP обов'язкова на цільовому веб-вузлі	Потрібна лише на стороні шлюзу VPN
Прохідність крізь Middlebox	Низька (Блокується фаєрволами та NAT)	Висока (Стандартний шифрований трафік UDP)
Час відновлення зв'язку	Потребує узгодження нового підпотоку	Миттєво (Атомарний запис у таблицю ядра)
Прозорість для додатків	Висока (Через стандартні сокети Posix)	Повна (Віртуальна карта ізолює систему)
Захист метаданих	Відсутній (IP-заголовки передаються відкрито)	Надійний (Усі кінцеві адреси замасковані)

Практичні поради для побудови стабільного мобільного зв'язку

Під час організації мобільного захищеного підключення варто спиратися на перевірені інженерні стандарти:

Ізолюйте системний трафік віртуальним адаптером: Спрямовуйте критичний трафік крізь авторизований VPN-тунель Layer 3. Фіксація сокетів на віртуальному адаптері гарантує, що зміна фізичного каналу не порушить сесій високого рівня.
Обирайте тунелі на основі протоколу UDP без збереження стану: Уникайте передачі трафіку всередині зовнішніх з'єднань TCP (як у старих версіях OpenVPN). Використання TCP всередині TCP при втратах пакетів призводить до колапсу швидкості (TCP Meltdown).
Активуйте періодичне надсилання Keepalive: У налаштуваннях мобільного VPN встановлюйте інтервал надсилання службових пакетів у межах 20–25 секунд. Це зберігає відкритими таблиці трансляції NAT у мобільних операторів, забезпечуючи миттєву доставку пакетів зі шлюзу.
Утримуйте DNS-запити всередині зашифрованого тунелю: Налаштуйте примусову передачу запитів DNS лише крізь віртуальний інтерфейс, щоб службові налаштування DHCP стільникових мереж не перехоплювали резолвери під час зміни зв'язку.

Multipath TCP є перспективною розробкою, проте бар'єри мережевого обладнання та брак універсальної підтримки на серверах обмежують його масове використання. Роумінг на рівні VPN Layer 3 забезпечує надійне вирішення проблеми мобільності, гарантуючи пристроям безперервний перехід між Wi-Fi та 5G без обривів зв'язку, затримок та загроз для безпеки даних.

Завантажити VPNRice.