Два излезни канали, но еден тунел: префрлање, балансирање или поврзување
Префрлање при дефект, балансирање по тек и поврзување на еден тек се три различни ветувања. Две стандардни рути ви го даваат првото, но не и другите две.
Две интернет линии можат да го направат 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
Кога единствениот пренос сѐ уште користи еден излезен канал, проектот го прави точно она што го подразбира хашот на тек. Кога паралелните преноси се распоредуваат на двете, балансирањето работи, а агрегацијата не. Запишете кое од трите ветувања проектот навистина го држи, и следниот разговор за капацитет ќе започне од докази, не од тврдење на добавувач.