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