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