Два висхідні канали, але один тунель: перемикання, балансування чи об’єднання
Перемикання при збої, балансування за потоками та об’єднання одного потоку — це три різні обіцянки. Два маршрути за замовчуванням дають першу, але не дві інші.
Дві інтернет-лінії можуть зробити 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Коли єдина передача досі використовує один висхідний канал, проєкт робить рівно те, що передбачає хеш потоку. Коли паралельні передачі розподіляються по обох, балансування працює, а агрегація — ні. Запишіть, яку з трьох обіцянок проєкт справді дотримує, і наступна розмова про ємність почнеться з доказів, а не із заяви постачальника.