Multipath TCP (MPTCP) — расширение TCP, которое позволяет одному логическому соединению работать через несколько путей (например, два провайдера, две NIC, VPN плюс прямой канал). С практической точки зрения это даёт две ключевые возможности: failover (сессия переживает отвал одного канала) и потенциальный рост throughput (часть трафика идёт параллельно по нескольким путям).
В контексте серверов тема особенно интересна, когда у вас есть минимум два независимых пути или адреса, которыми реально можно пользоваться: IPv4 и IPv6, основной и дополнительный IP, прямой интерфейс и туннель. На VDS это чаще всего достижимо без сложной физической инфраструктуры.
Важно: MPTCP работает только если обе стороны соединения его поддерживают (клиент и сервер). Если одна сторона «обычный TCP», MPTCP не включится. Поэтому типичный сценарий — «ваш Linux-хост ↔ ваш сервер», где вы контролируете конфигурацию на обеих сторонах.
Как устроен MPTCP: subflow, endpoint и path manager
Для настройки и отладки полезно понимать базовые термины:
- subflow — отдельный TCP-поток внутри одного MPTCP-соединения. Их может быть несколько, обычно по числу доступных путей/адресов.
- endpoint (address) — адрес (IPv4/IPv6), который MPTCP может анонсировать другой стороне, чтобы та подняла дополнительные subflow.
- path manager — логика создания subflow: когда добавлять новые пути и какие адреса рекламировать. В Linux часто используется модель с явным добавлением endpoints через iproute2.
Стабильность соединения при отвале интерфейса достигается тем, что приложение «видит» одно соединение, а ядро перестраивает набор subflow: пока есть хотя бы один живой путь, сессия сохраняется.
Проверяем поддержку MPTCP в вашем Linux
Во многих современных дистрибутивах ядро уже включает MPTCP, но в минимальных образах VDS или старых LTS это стоит проверить заранее.
Проверка ядра и sysctl
uname -r
sysctl net.mptcp.enabledОжидаемо увидеть net.mptcp.enabled = 1. Если параметр отсутствует, это признак, что ядро собрано без MPTCP или функциональность недоступна в текущем окружении.
Включить (если доступно):
sysctl -w net.mptcp.enabled=1Для постоянного применения добавьте параметр в конфигурацию sysctl (обычно в /etc/sysctl.d/) и примените:
sysctl --system
Базовая лабораторная схема для VDS: «два адреса» как два пути
Проще всего пощупать MPTCP, когда у каждой стороны есть два адреса, которые реально маршрутизируются. На практике на VDS это чаще всего один из вариантов:
- IPv4 и IPv6 (два стека; иногда и два разных маршрута);
- основной IPv4 и дополнительный IPv4 (secondary/alias);
- второй путь через туннель (например, WireGuard) и отдельную подсеть.
Дальше предполагаем, что и клиент, и сервер — Linux, и вы можете управлять адресами на обеих сторонах.
Если ваша «вторая линия» — это IPv6, полезно заранее проверить, как у вас устроена выдача адресов и маршрутизация: SLAAC/DHCPv6 и базовая маршрутизация IPv6.
iproute2: добавляем endpoints и проверяем subflow
Управление MPTCP в Linux выполняется через ip (iproute2). Важная мысль: MPTCP не «включается сам» — вы явно задаёте, какие адреса можно рекламировать и какие subflow разрешены.
Смотрим текущее состояние MPTCP
ip mptcp help
ip mptcp endpoint show
ip mptcp limits showЕсли ip mptcp недоступен, обычно помогает обновление iproute2 до актуальной версии из репозиториев вашего дистрибутива (или backports). На некоторых системах команда есть, но набор подкоманд может отличаться.
Добавляем endpoints (пример IPv4 плюс IPv6)
Допустим, на сервере есть два адреса на eth0: один IPv4 и один IPv6. Добавим их как endpoints, чтобы MPTCP мог анонсировать их пиру:
ip mptcp endpoint add 203.0.113.10 dev eth0 id 10 signal
ip mptcp endpoint add 2001:db8:10::10 dev eth0 id 20 signal
ip mptcp endpoint showФлаг signal означает «рекламировать адрес peer-у», чтобы он мог инициировать дополнительные subflow. Не рекламируйте адреса управления или приватные подсети, если они не должны использоваться для внешних соединений.
Лимиты на количество subflow
Если дополнительные subflow не создаются, частая причина — слишком маленькие лимиты. Проверьте:
ip mptcp limits showИ при необходимости увеличьте (значения подбирайте разумно под вашу задачу):
ip mptcp limits set subflow 4 add_addr_accepted 4
ip mptcp limits show
Проверяем, что трафик реально MPTCP, а не обычный TCP
Самая частая ошибка — «всё настроил, но фактически работает обычный TCP». Базовая диагностика делается через ss, а при спорных ситуациях подключайте захват трафика на обеих сторонах.
ss: смотрим MPTCP-сокеты и subflow
ss -tM
ss -tMiКлючи могут немного отличаться по версиям ss, но цель одна: увидеть MPTCP-соединения и привязанные к ним subflow. В выводе ищите несколько subflow для одного логического соединения.
Тест failover «вживую»
Если у вас реально два пути (например, IPv4 и IPv6, или два интерфейса), можно имитировать отвал одного пути и посмотреть, удержится ли сессия:
- Поднимите долгую передачу (скачивание большого файла, rsync, длительный HTTP/2 поток).
- Временно «сломайте» один путь: снимите адрес, измените policy routing или точечно ограничьте исходящий трафик для одного источника/маршрута.
- Наблюдайте
ss -tMi: один subflow должен умереть, но соединение должно сохраниться на оставшемся пути.
На VDS «выдернуть кабель» нельзя, поэтому аккуратнее всего тестировать в окне обслуживания и максимально точечно: ломайте конкретный путь, а не весь сервис.
Почему throughput может не вырасти (и это нормально)
Ожидание «сложу два канала и получу x2» срабатывает не всегда. Типовые причины:
- Ограничения приложения: упор в CPU, диск или TLS может быть сильнее, чем в сеть.
- Разные RTT и потери: если один путь заметно хуже, scheduler будет использовать его осторожно.
- Узкие места вне вашего контроля: оба пути могут сходиться в один и тот же аплинк, и реальной независимости нет.
- Очереди и буферы: агрегация путей меняет поведение очередей и контроля перегрузки.
MPTCP — в первую очередь про устойчивость и качество сервиса на нестабильных каналах. Ускорение — возможный бонус, но не гарантия.
nftables и MPTCP: что учесть в firewall
MPTCP создаёт дополнительные subflow, а значит могут появляться новые «легитимные» TCP-соединения между теми же хостами, но с другими парами адресов и портов (в рамках MPTCP-логики). Слишком жёсткие правила «разрешить только один IP-источник» или «разрешить только один интерфейс» часто ломают создание subflow.
Практические рекомендации:
- Разрешите входящий TCP на нужный сервис (например, 443) для всех адресов, которые планируете использовать как endpoints.
- Если у вас строгая логика на
ct state, убедитесь, что новые соединения на нужные порты не отсекаются. - При policy routing проверяйте симметричность маршрутов: subflow может прийти на один адрес, а уйти через другой провайдер, и это не всегда допустимо в вашей схеме.
Если делаете «управляемый failover» через firewall (временно блокируя один путь), делайте это точечно по адресу или таблице маршрутизации, чтобы не уронить весь сервис.
systemd-networkd и автоприменение MPTCP после старта сети
Сам MPTCP обычно настраивается через ip mptcp, но качество работы напрямую зависит от того, как заданы адреса, маршруты и policy routing. Если используете systemd-networkd, придерживайтесь простой логики:
- адреса (включая secondary) описывайте в .network файлах;
- маршруты и правила (policy routing) задавайте декларативно, чтобы после перезагрузки всё восстанавливалось;
- команды
ip mptcp endpoint addиip mptcp limits setприменяйте через systemd unit (oneshot) после поднятия сети.
Пример unit для автоприменения endpoints
Адреса подставьте свои. Обратите внимание: если unit запускается повторно, добавление endpoints может возвращать ошибку «уже существует» — это нормально для идемпотентности, но в проде часто удобнее предварительно чистить список или проверять наличие.
[Unit]
Description=Configure MPTCP endpoints
After=network-online.target
Wants=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/ip mptcp limits set subflow 4 add_addr_accepted 4
ExecStart=/usr/sbin/ip mptcp endpoint add 203.0.113.10 dev eth0 id 10 signal
ExecStart=/usr/sbin/ip mptcp endpoint add 2001:db8:10::10 dev eth0 id 20 signal
ExecStart=/usr/sbin/ip mptcp endpoint show
RemainAfterExit=yes
[Install]
WantedBy=multi-user.targetОтладка: почему subflow не поднимаются
Если MPTCP «включён», но дополнительных subflow нет, идите по чек-листу:
- Обе стороны поддерживают MPTCP и
net.mptcp.enabledвключён. - Добавлены endpoints с
signal, и эти адреса реально назначены на интерфейс. - Для каждого адреса есть корректный исходящий маршрут; при нескольких таблицах маршрутизации особенно важны правила и метрики.
- Firewall/NAT не режет новые TCP-соединения и не ломает адресацию (в сложных схемах это критично).
- Наблюдаемость:
ss -tMiпоказывает попытки subflow и их состояние.
В спорных случаях помогает одновременный захват трафика на обеих сторонах и сравнение: ушёл ли сигнал ADD_ADDR, была ли попытка subflow, пришёл ли ответ, на каком шаге разрыв.
Где MPTCP реально уместен в MultiWAN-сценариях
MPTCP не заменяет MultiWAN-маршрутизатор. MultiWAN отвечает на вопрос «куда отправлять пакеты», а MPTCP — «как сохранить соединение и распределить поток между путями, если эти пути есть».
Рабочая модель обычно такая:
- у клиента (офис/дом) два провайдера и Linux-шлюз с policy routing;
- на серверной стороне есть два независимых пути (IPv4 плюс IPv6, или туннель как второй путь);
- критичные сервисы (админка, API, синхронизация) переводятся на MPTCP-совместимую схему там, где вы контролируете обе стороны.
Безопасность и эксплуатация
MPTCP сам по себе не шифрует трафик и не заменяет TLS или VPN. Он меняет транспортный уровень, поэтому в эксплуатации важно:
- пересмотреть модель разрешённых адресов и портов (легитимных соединений станет больше);
- не рекламировать endpoints, которые не должны быть доступны извне (управляющие адреса, приватные сети);
- мониторить количество subflow, частоту переключений, потери и RTT по путям как ранние индикаторы деградации;
- регулярно прогонять тесты: «падение одного пути», «восстановление пути», «перезагрузка одной стороны».
Если вы используете IPv6 как резервный путь, заранее убедитесь, что у вас корректно работает базовая инфраструктура IPv6 на VDS: NAT64/DNS64 и нюансы доступа к IPv4-ресурсам из IPv6.
Мини-резюме
MPTCP в Linux особенно хорошо раскрывается, когда вы контролируете обе стороны соединения и можете дать минимум два независимых пути. На VDS это чаще всего «IPv4 плюс IPv6», «основной плюс дополнительный IP» или «прямой канал плюс туннель». Практическая настройка сводится к включению MPTCP в ядре, добавлению endpoints через ip mptcp, корректной маршрутизации и проверке через ss. Для стабильного failover важнее всего маршруты и firewall, а для роста throughput — реальная независимость путей и отсутствие внешних узких мест.
