LINUX.ORG.RU
ФорумAdmin

Интернет через несколько 3G-модемов одновременно

 , ,


0

2

Есть связка модемов с разными симками (в теории еще может быть вайфай) и низкой скоростью, охота пускать каждое соединение через все доступные интерфейсы СРАЗУ, а не в случае полного отваливания сети или сорт-оф балансировки маршрутов. Получившийся интернет раздать локально через вайфай на андроид-девайс.

А теперь вопросы:

1. что может рандомно распределять пакеты по имеющимся интерфейсам?

2. что может висеть на промежуточном сервере и собирать пакеты в цельную сессию, выпуская ее в реальный инет?

3. стоит ли поднимать кучу впн-сессий для кадого провайдера, или это будет большой оверхед?

4. реализуема ли затея вообще? (я так понимаю, что если один из провайдеров отвалился, все остальные будут ждать потерявшийся пакет и пока по другому интерфейсу повтор не прибежит, tcp-сессия в это время висит)

готов набыдлокодить пару велосипедов, но пока не знаю как они даже выглядеть должны

Все бы ничего, но они все приватные адреса используют. Ты установишь соединение через одного провайдера, а у другого оно в таблице conntrack отсутствует, соответственно его NAT не пропустит пакеты.

anto215 ★★ ()
Ответ на: комментарий от anto215

А мне оно надо? Транспортный уровень - это впн или даже про юдп (в особо упоротом виде посылка пост-хттп запросов), только бы до сервера долететь.

nogaemz ()
Ответ на: комментарий от MikeDM

Какой именно? Есть мануал для моего случая? Находил пока только поделки школьников (потому проще самому сделать, чем юзать такое)

nogaemz ()
Ответ на: комментарий от anonymous

The current MPTCP code can be found at the MPTCP github repository; it adds a good 10,000 lines to the mainline kernel's networking subtree. While it has apparently been the subject of discussions with various networking developers, it has not, yet, been posted for public review or inclusion into the mainline. It does, however, seem to work: the MPTCP developers claim to have implemented the fastest TCP connection ever by transmitting at a rate of 51.8Gb/s over six 10Gb links.

MPTCP is still relatively young, so there is almost certainly quite a bit of work yet to be done before it is ready for mainline merging or production use. There is also some thinking to be done on the application side; it may be possible for MPTCP-aware applications to make better use of the available paths. Projects like this are arguably never finished (we are still refining TCP, after all), but MPTCP does seem to have reached the point where more users may want to start experimenting with it.

Не, надо такое, дабы само трафик шифровало (по крайней мере обфусцировало от натов) и работало точно везде, прикидываясь ветошью, как это делает опенвпн

nogaemz ()

Лучший (менее костыльный) вариант — Multipath TCP, как вам уже рекомендовали выше. Поверх него вы можете тот же OpenVPN через TCP завести, и будет работать.

Если вы категорически не хотите использовать Multipath TCP, то городите bonding с использованием OpenVPN TAP, наверное.

ValdikSS ★★★★★ ()
Ответ на: комментарий от ValdikSS

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

Боундинг, если я правильно понимаю, просто будет переключать каналы, т.е. если скорость линка 5 килобит, то толку от такого интернетта мне не будет, в отличии от МРТСР?

nogaemz ()
Ответ на: комментарий от nogaemz

В описании сказано, что если по пути будет какой-то хитрожопый роутер, то скорее всего дополнительные линки не будут работать

Я такого не помню, но вы всегда можете проверить, установив ядро с патчами multipath и зайти на сайт http://amiusingmptcp.com/.

Бондинг работает так, как вы его настроите. Я, правда, не до конца уверен, что он будет работать правильно в случае VPN (а не физический сетевых устройств).

Вам нужно, чтобы каждый пакет выходил через рандомное соединение. Таким образом, одно TCP-подключение у вас будет распараллеливаться правильно. Естественно, точка терминирования соединений должна быть одна (VPS, например).

ValdikSS ★★★★★ ()
Ответ на: комментарий от ValdikSS

Ради проверки мне придется приехать в другую страну и купить там килограм симок, будет большое разочарование, если оно работать не будет. Возможно, даже поплакаться не смогу. Про бондинг я спросил потому, что сам не до конца понимаю его работу, везде пишут, что он на случай падения канала, что ге мой случай.

Опять же, не любая впска годится, нужна такаф, которая не будет дропать неизвестные ей пакеты. И если уж совсем быть занудой, то не рандомно, а выбирать наиболее доступный канал.

К чему я? Я хочу более изолированное решение, которое откроет что-то вроде десятка туннелей и просто будет гонять пакеты, а на впске все будет собрано. Конечно, за неимением лучшего, я буду вынужден попробовать и такой вариант

nogaemz ()
Ответ на: комментарий от ziemin

Можно. Хватаем локально пакеты, режем на части, отправляем через разные интерфейсы, на промежуточном сервере склеиваем, изображаем нат и шлем в интернет. Вопрос только чем это сделать.

nogaemz ()
Ответ на: комментарий от nogaemz

Вопрос только чем это сделать.

А меня больше интересует кто будет склеивать, и, если это возможно, как относяться к таким финтам провайдеры.

ziemin ★★ ()
Ответ на: комментарий от nogaemz

Вопрос только чем это сделать

MPTCP поверх OpenVPN? я не пробовал, но не видно причин чтобы не заработало

anonymous ()
Ответ на: комментарий от ziemin

Почему нельзя? Я в своё время думал над подобной штукой для организации быстрого канала из пачки модемов с edge.

У меня нарисовался вариант с «растянутым» socks-proxy и промежуточным сервером. На клиентской стороне софту скармливается локальный сокс-прокси, далее прокся хватает пакеты и в простейшем случае раунд-робином рассовывает их по модемам. Всё это идёт на промежуточный сервер с нормальным каналом, где собирается в исходные пакеты и отправляется по назначению. При получении ответа он точно так же разбивается по интерфейсам и послылается клиенту, где собирается в исходный пакет и отдаётся в проксю приложению.

Впрочем, дальше констатации «решение есть» дело не пошло - самому писать было лень, а готового ничего не нашлось. Про multipath-tcp я не знал.

Deleted ()
Ответ на: комментарий от anonymous

Но если хочется сделать свой MultiPath-IP (или даже MultiPath-Ethernet), наверное не очень сложно будет навелосипедить в юзерспейсе (tun/tap)

Поднимаем несколько VPN-тоннелей, сообщаем их параметры своему демону. Нужный трафик заворачиваем в свой tun/tap интерфейс, демон инкапсулирует его и раскидывает по тоннелям. А на другом конце соотв. разворачивает

Удивительно, но такое не гуглится, хотя наверняка кто-то делал

anonymous ()
Ответ на: комментарий от nogaemz

Опять же, не любая впска годится, нужна такаф, которая не будет дропать неизвестные ей пакеты.

Любая, кроме как на OpenVZ (на ней не заведете свое ядро с Multipath).

Про бондинг я спросил потому, что сам не до конца понимаю его работу, везде пишут, что он на случай падения канала
Ethernet bonding — это объединение двух или более физических сетевых интерфейсов в один виртуальный для обеспечения отказоустойчивости и повышения пропускной способности.
и повышения пропускной способности

Почему я так вам советую Multipath TCP, а не Bonding? Я его сам пробовал на 3 каналах: проводной, Wi-Fi и 3G. Работало.

К чему я? Я хочу более изолированное решение, которое откроет что-то вроде десятка туннелей и просто будет гонять пакеты, а на впске все будет собрано.

Вы можете попробовать сделать несколько L2 туннелей и бондинг между ними, но я не совсем уверен, что он сработает (зависит от типа бондинга и самих туннелей). А вот Multipath TCP заработает, настраивается заметно проще бондинга и работает стабильно.

ValdikSS ★★★★★ ()
Ответ на: комментарий от nogaemz

пакеты, режем на части

Лучше не надо резать пакет на части, ничего хорошего это не даст, только данных будет ещё больше, а прироста по скорости не будет. Как уже посоветовали, раскидывайте пакеты по интерфейсам и отдельный самописный костыль, который бы менял правила распределения пакетов (проверял, что все соединения рабочие).

mky ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.