Два восходящих канала, но один туннель: переключение, балансировка или объединение
Переключение при сбое, балансировка по потокам и объединение одного потока — три разных обещания. Два маршрута по умолчанию дают первое, но не остальные два.
Две интернет-линии могут сделать VPN доступнее, а некоторые нагрузки — быстрее, но то, что именно произойдёт, определяет механизм. Маршрутизатор с двумя маршрутами по умолчанию не объединён, а туннель, несущий тысячи внутренних соединений, всё равно остаётся одним внешним потоком. Назвать обещание первым — это разница между проектом и дорогим разочарованием. Таблица ниже разделяет варианты по тому, что каждому нужно на дальнем конце и что потеря канала делает с передачей.
Три обещания, и только одному нужен партнёр
Переключение при сбое сохраняет путь доступным, когда предпочтительный канал исчезает. Балансировка по хешу потоков распределяет независимые потоки по обоим восходящим каналам. Объединение одного потока позволяет одной передаче использовать оба канала одновременно. Это разные продукты с разными требованиями, и только последнему нужно сотрудничество чего-то за пределами вашего маршрутизатора.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
Ничто в этой таблице не является причиной покупать вторую линию. Она делает другое: не даёт оценивать проект переключения так, будто это объединение.
Почему туннель выглядит для маршрутизатора как один поток
Маршрутизатор с балансировкой нагрузки хеширует адреса источника и назначения вместе с портами, а затем отправляет весь поток туда, куда указывает хеш. Туннель VPN с точки зрения маршрутизатора — один такой поток, что бы ни работало внутри него. Внутренние соединения никогда не доходят до решения о хеше, потому что внешний заголовок уже определил путь. Поэтому второй восходящий канал может удвоить общую ёмкость для многих пользователей и ничего не изменить в большой передаче одного пользователя.
Два отдельных туннеля могут дать двух кандидатов, но им всё ещё нужна намеренная политика, которая распределяет трафик и удерживает ответы на пути, по которому ушёл запрос. Асимметричная маршрутизация — обычный результат пропуска этого шага. Минимум — политика, которая называет поток, предпочтительный канал и резервный канал.
Объединение Ethernet не проходит через несвязанных провайдеров, потому что дальний конец должен участвовать в протоколе агрегации. Объединение через двух интернет-провайдеров — исследовательский проект, если только не существует взаимодействующий конечный узел.
Что нужно многопутевому TCP на обоих концах
Документация Linux по Multipath TCP описывает несколько подпотоков, принадлежащих одному соединению. Поддержка ядра на одном конце сама по себе ничего не меняет, поскольку партнёр тоже должен принимать эти подпотоки. Прокси на дальней стороне — другая распространённая схема, и он становится компонентом с собственной ёмкостью и доступностью, которые нужно планировать. Та же логика исключает простое решение для WireGuard, транспорт которого — UDP: MPTCP наращивает подпотоки TCP и не может объединить этот туннель без чего-то ещё в проекте.
Проверьте, включена ли функция ядра, прежде чем проектировать вокруг неё, поскольку многие дистрибутивы поставляют её выключенной. Эти три команды отвечают на это за минуту.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showВыбирайте по нагрузке, а не по брошюре
Если нагрузка — множество независимых сессий, балансировка по хешу может добавить ёмкость без сотрудничества на дальнем конце. Если это одна большая передача, поможет только проект агрегации, и такому проекту нужен взаимодействующий партнёр. Если требование в том, чтобы работа продолжалась при гибели канала, ответ — переключение, а пропускная способность одной передачи не имеет значения.
Запишите требование одним предложением с глаголом: одна резервная копия завершается вдвое быстрее, или упавший канал не завершает сеанс. Расплывчатые цели дают проекты, которые никто не может ни принять, ни отклонить. Затем решите, чем может быть дальний конец, потому что самый дешёвый вариант часто тот, который не требует там ничего нового. Это ограничение убирает большинство заявлений из брошюры ещё до первой встречи.
Держите три обещания отдельно в документе требований. Проект, который заявляет все три, обычно даёт одно и молча предполагает остальные. Следующий раздел проверяет, что именно даётся.
Проверьте одну передачу и много, затем выдерните канал
Сравните одну непрерывную передачу с несколькими параллельными передачами к тому же адресату, и запишите потери, задержку и загрузку каждого канала. Выигрыш только при параллельных сессиях указывает на распределение потоков, а не на агрегацию одного потока. Проверьте потерю одного восходящего канала отдельно, потому что ёмкость при работающих обоих каналах ничего не говорит о переключении для уже установленного сеанса. Фиксируйте маршрут, сокет и счётчики повторных передач до и после каждого теста.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Когда единственная передача по-прежнему использует один восходящий канал, проект делает ровно то, что подразумевает хеш потока. Когда параллельные передачи распределяются по обоим, балансировка работает, а агрегация нет. Запишите, какое из трёх обещаний проект действительно соблюдает, и следующий разговор о ёмкости начнётся с доказательств, а не с заявления поставщика.