OpenMPTCProuter. Выжимаем все соки из слабой сети

Решение из учебника

За­дача «обес­печить ста­биль­ную связь где‑то за городом» с началом дач­ного сезона акту­аль­на как никог­да. Пред­ста­вим, что у нас есть толь­ко нес­коль­ко симок и инже­нер­ная сме­кал­ка.

Сра­зу нап­рашива­ется решение — под­клю­чить нес­коль­ко модемов с раз­ными сим­ками и балан­сировать под­клю­чения по ним. Наружу тор­чит один интерфейс, на котором при­нима­ются пакеты, а затем они отправ­ляют­ся в сеть через выб­ранный модем в зависи­мос­ти от при­над­лежнос­ти к кон­крет­ному соеди­нению (что­бы пакеты одно­го соеди­нения не ухо­дили через раз­ные модемы). Балан­сировать соеди­нения по модемам мож­но по round robin, по наимень­шему чис­лу соеди­нений или даже прос­то слу­чай­но — боль­шого зна­чения это не име­ет.

В целом такое решение воз­можно, и оно даже будет как‑то работать. Но пол­ностью исполь­зовать всю про­пус­кную спо­соб­ность при таком под­клю­чении вый­дет раз­ве что по про­токо­лу BitTorrent (который сам по себе заб­локиро­ван у мно­гих мобиль­ных опе­рато­ров), который дер­жит одновре­мен­но мно­го соеди­нений и гаран­тирован­но хоть по одно­му соеди­нению попадет на каж­дый из модемов.

Нор­маль­ные TCP-соеди­нения при нес­табиль­ном при­еме сиг­нала от раз­ных опе­рато­ров будут напоми­нать извес­тную игру про револь­вер с непол­ным бараба­ном, где никог­да заранее не зна­ешь, уйдет пакет или выпав­ший соеди­нению модем лежит. В резуль­тате если один модем работа­ет нор­маль­но, а дру­гой тупит — часть соеди­нений будет летать, а дру­гая, менее удач­ливая часть гру­зить в час по чай­ной лож­ке. Ну и при обры­ве свя­зи некото­рые соеди­нения пор­вутся, а дру­гие — нет.

Проб­лему с обры­вом час­ти соеди­нений обыч­но пыта­ются лечить уста­нов­кой тун­неля и про­пус­кани­ем все­го тра­фика через него. Тог­да тун­нель, ког­да связь прер­вется, будет пере­уста­нав­ливать соеди­нение через дру­гой модем, а иду­щий внут­ри тра­фик ничего не заметит. С этим воз­ника­ет дру­гая проб­лема: мак­сималь­ная ско­рость такого ком­биниро­ван­ного канала будет чуть мень­ше ско­рос­ти того модема, на который он выпал пря­мо сей­час, а вто­рой модем будет вооб­ще про­игно­риро­ван.

Для прос­тей­шей балан­сиров­ки соеди­нений на самых популяр­ных роуте­рах даже не нуж­но ничего изоб­ретать: поч­ти все они из короб­ки под­держи­вают фун­кции вро­де Dual WAN или load balancing.

Dual WAN и ее раз­новид­ности (WAN failover в D-Link, Allow failback в Asus, Link backup в TP-Link и про­чие) — самый при­митив­ный и дубовый вари­ант: он отсле­жива­ет дос­тупность интерне­та через глав­ный канал и перек­люча­ется на резер­вный при ошиб­ке основно­го. Ни о каком одновре­мен­ном исполь­зовании тут речи не идет, а пока основной линк хоть сколь­ко‑нибудь работос­пособен — резер­вный не будет исполь­зовать­ся, даже если он работа­ет иде­аль­но, в отли­чие от основно­го. Как понят­но из наз­вания фун­кции, это нуж­но как ава­рий­ное решение на слу­чай вне­зап­ной ава­рии основно­го опе­рато­ра, а не для пос­тоян­ной лов­ли луч­шего качес­тва свя­зи.

Load balancing пыта­ется рас­кидывать соеди­нения по нес­коль­ким аплинкам сра­зу, но более‑менее жиз­неспо­соб­но оно толь­ко на MikroTik (нас­трой­ка которо­го для рядово­го юзе­ра силь­но за гра­ница­ми зоны ком­форта), а на осталь­ных пот­ребитель­ских желез­ках ее исполь­зовать не сто­ит даже пытать­ся из‑за откро­вен­но пло­хой работы. Хотя на бумаге зву­чит поч­ти хорошо.

Load balancing на MikroTik

Ес­ли ты все же решишь сде­лать балан­сиров­ку соеди­нений на MikroTik, нуж­но исполь­зовать PCC (per connection classifier). Это такая хеш‑фун­кция, которая гаран­тиру­ет попада­ние всех пакетов из одно­го потока по одно­му и тому же мар­шру­ту. Для нас­трой­ки задай роуте­ру адре­са в под­сетях каж­дого исполь­зуемо­го опе­рато­ра, соз­дай мар­шру­ты к 0.0.0.0/0 с раз­ным distance, вклю­чи Check gateway: ping и задай пра­вила фай­рво­ла для таб­лицы mangle:

Rule 1 - Mark Connection provider 1:

Chain: prerouting

In. Interface: <LAN>

Connection Mark: no-mark

New Conn. Mark: ISP1-Conn

Per Connection Classifier: both-addresses:2/0

Passthrough: Yes

Rule 2 - Mark Connection provider 2:

Chain: prerouting

In. Interface: <LAN>

Connection Mark: no-mark

New Conn. Mark: ISP2-Conn

Per Connection Classifier: both-addresses:2/1

Passthrough: Yes

Rule 3 - Mark Routing provider 1:

Chain: prerouting

Connection Mark: ISP1-Conn

New Routing Mark: via-ISP1

Passthrough: No

Rule 4 - Mark Routing provider 2:

Chain: prerouting

Connection Mark: ISP2-Conn

New Routing Mark: via-ISP2

Passthrough: No

При­мер выше — для балан­сиров­ки 50/50. Что­бы раз­делить в дру­гом соот­ношении, надо добавить нес­коль­ко пра­вил. Для это­го про­пиши клас­сифика­торы вро­де both-addresses:3/0 и both-addresses:3/1 на ISP1 и both-addresses:3/2 на ISP2, что­бы два из трех соеди­нений выбира­лись на пер­вого про­вай­дера, а один из трех — на вто­рого.

Пос­ле это­го надо соз­дать нес­коль­ко таб­лиц мар­шру­тиза­ции (по одной на каж­дого опе­рато­ра), в каж­дой из которых соз­дать мар­шрут к 0.0.0.0/0 через соот­ветс­тву­ющий шлюз (нап­ример, 0.0.0.0/0 via 192.168.2.1 в таб­лице via-ISP2).

Ес­тес­твен­но, для защиты от раз­рыва дол­гоживу­щих TCP-соеди­нений таким методом при­дет­ся обер­нуть весь тра­фик в тун­нель, что­бы при перепод­клю­чении тун­неля соеди­нения внут­ри не обры­вались. Но нас­трой­ка таких тун­нелей уж точ­но выходит за рам­ки этой статьи, тем более что сей­час такие решения извес­тны как никог­да широко.

Всё везде и сразу

Опи­сан­ное выше решение спра­вит­ся с проб­лемой обры­ва слу­чай­ных соеди­нений, но не поможет дей­стви­тель­но про­сум­мировать лин­ки. При нес­табиль­ной работе сети (нап­ример, при дви­жении в машине), да и в осталь­ных слу­чаях тоже, луч­ше бы по‑нас­тояще­му сум­мировать пол­ную про­пус­кную спо­соб­ность соеди­нения.

Для это­го сущес­тву­ет про­токол Multipath TCP, который пус­кает пакеты одно­го TCP-соеди­нения раз­ными мар­шру­тами в сети. Пос­коль­ку под­держи­вает­ся он очень мало где, будет нужен про­межу­точ­ный сер­вер, который собира­ет из таких раз­номар­шрут­ных пакетов клас­сичес­кий TCP-поток и отправ­ляет к точ­ке наз­начения.