Открыть список
Как стать автором
Обновить

Комментарии 51

Интересная бюджетная схема.
С центральным сервером все понятно. Но два LTE-интерфейса на mikrotik — вы использовали плату с двумя и выше minipcie слотами? Какие модемы? Интересно конкретное оборудование с точки зрения надежности.
По факту подойдет любое оборудование Mikrotik, как с LTE-модулями, так и без, можно с одним модулем и одним usb-модемом.
Все зависит от производительности роутера и наличия необходимых интерфейсов. У меня был в наличии mikrotik ltap mini lte kit и обычный mikrotik с usb-модемом. А так «вкусным» решением вижу mikrotik RBM33G + 2шт mikrotik r11e-lte6 + корпус + 2 внешние антенны. Но может быть и такой mikrotik lhg lte 6 kit — 2шт и RouterBOARD 750G r3.
много видел таких решений на базе mikrotik плюс usb хаб = стотыщ usb-модемов. Потому и спрашиваю — может, уже собрали и потестировали что-то более адекватное. Например, у mti-group были свои модемы сильно дешевле микротиковских, на которых они демонстрировали свои решения. Собственно, у них же есть готовые комплекты для описанных схем, скорее всего именно на базе rbm33g.
Какое-то масло масляное.
В конце предложу варианты решения для менее скромного бюджета – для крупных заказчиков.

крупные заказчики найдут ресурсы для организации надежной последней мили (хотя бы WiMax) и им, как правило, такие поделки очень портят качество канала. Там и с MTU не «поиграть» — 1520 байт хоть расшибись, а отдай. И Q-In-Q свой туда же не говоря про остальные параметры SLA.
Зачем столько туннелей? Почему нельзя было сделать разу EoIP+ipsec, поверх них бондинг и на этом всё?
EoIP не поднимается с серыми IP за натом.
Да, действительно. Но предназначение openVPN туннеля внутри бондинга всё равно остаётся неясным.
Чистый IPsec + XXIP поднимается.
ipsec умеет выдавать виртуальные адреса

Можно использовать IPsec в туннельном режиме и поверх него уже GRE, IPIP, XXoIP и вообще что угодно. То есть, L2TP из связки можно исключить.

Зачем внутри шифрованного L2TP шифрованный OpenVPN?
Зачем вообще OpenVPN в этой схеме? Судя по статье, интерфейс ovpn_over_bonding1 используется только для маршрутизации, но ведь уже есть интерфейс bonding1 и для маршрутизации можно использовать его.
OpenVPN поверх bonding используется не для маршрутизации, без него работать не будет, проверено.
L2TP или другие туннели необходимы для связки, внутри которых поднимается L2-туннели EoIP. Агрегировать можно OpenVPN или EoIP — в bonding можно добавить только эти туннели.
BCP, честно говоря, не пробовал. Спасибо, посмотрю, так сразу сложно сказать.

Почему без ovpn не будет работать?
я делал подобную схему и там сразу на bonding всё работало.

OVPN сверху не нужен. Только что собрал вашу схему — на Bond вешается IP, поверх него ходят OSPF.
Не соглашусь, без OpenVPN куча дропов в режиме broadcast в bonding и пакеты ходят странным образом (к примеру, ICMP).

У вас отваливается маршрутизация, вы ее решаете костылями OVPN.

Интересная статья. Нужно попробовать на торговых точках будет.
Немного конструктивной критики:
1) MII мониторинг бондинга: MII отслеживает только link state. Лучше бы использовать ARP.
2) Brodcast в бондинга даст просадку по худшему из каналов. ИМХО, active-backup подходит лучше.
Brodcast даст ширину канала как у худшего из каналов, но латентность как у лучшего из каналов.
Плюс дублирование даёт хорошую защиту от потерь пакетов, не 100%, но вероятность потери пакета сразу на двух каналах значительно ниже.
Поэтому при агрегации LTE, когда важнее получить более стабильный канал с шириной «как повезёт», лучше подходит broadcast.
Active-backup лучше подходит при агрегации стабильных каналов с разной шириной.
1) Возможно, нужно проверить.
2) Shrim ответил.
А почему 3des? А не AES256?
Тип шифрования не принципиален.
Спасибо, кстати, за статью вообще.
Спасибо. Рад, если статья была полезна.
А сравнивали разницу в скорости между «просто мобильный оператор связи» и ваш вариант? Хотя бы для интереса?
Скорость у меня уперлась во второго провайдера (МТС) — 10 Мбит, что аналогично трафику без агрегации напрямую с LTE-интерфейса. Немного подрастет время ответа, но тут все субъективно.
Зачем так сложно? шифрование — нужно ли вообще?
и зачем бондинг? почему не 2 GRE туннеля и не банальная настройка OSPF с BFD, классическая схема 2 канала между 2 роутерами.
Любую схему нужно тестировать. Я рассказал про схему, которая решила перечисленные проблемы в тех условиях, которые были у меня.
Понятно что, задачу нужно решить и с чем больше опыта с тем и работаем. Все верно.
Но вы попробуйте оверхеад посчитать и размер MTU в конечном openvpn.
Для GRE нужны концы тоннеля. Как быть с серыми IP?
Нужно ли шифрование — это можно у Яровой спросить.
Бондинг поверх 2х EoIP нужен для того, чтобы не ломался OSPF и моментально переключался на другой канал (или оба, как в данном случае). В случае с 2мя GRE будет определенное время на перестроение маршрутов, а это потеря пакетов и т.д.
Хорошо, 2 L2tp+IPSEС как у автора, но городить поверх этого bonding. Зачем, когда можно сразу с L3 работать?
Я не знаю зачем. Если речь про L3 от провайдера, то бывают разные ситуации и разные провайдеры. Про бондинг ответил выше, переключение active-backup срабатывает моментально на IKEv2 + EoIP + OSPF.
Я бы начал с того, что DPD у IKEv2 поставил секунд 5 и если схема позволяет использовал бы статику. Упал интерфейс туннельный, не стало маршрутов через него (у EoIP также есть keepalive интервал и пакеты также пропадут). если нужна прям динамика, то ospf на туннельных интерфейсах, лучше не в области 0. но конечно, надо пробовать.
Там где статика, там и направленная антенна. Область не так важна, это же не VPN с тоннами клиентов.
Сам себя поправлю, пока никто не заметил ) bfd на LTE эт я махнул конечно.
В данной схеме 2 GRE с keepalive внутри + статика тоже скорее всего сгодятся.

Зачем, если есть очень бюджетные и удобные Fortigate? Там и человеческая динамическая маршрутизация с любым вкусом, и SDWAN, и FEC, и агрегация туннелей и многое-многое-многое другое. Всё с отличным WUI/CLI.

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

Что ж, впервые за 10 лет я всё-таки зарегался на Хабре, чтобы оставить комментарий к этой инструкции.
Дорогой, автор, направление мысли исключительно правильное. Но почему в качестве тоннеля внутри уже шифрованного L2TP/IPsec ты выбрал ещё один l2 туннель с шифрованием OpenVPN?
Проблему гарантированного доступа давно решаю при помощи двух/трёх/и даже четырех тоннелей L2tp/IPsec, сагрегированных при помощи bounding и пропущенного через виртуальный интерфейс EoIP тоннеля. Более того, созданный интерфейс воспринимается микротиком как обычный Ethernet и позволяет безболезненно включить его в бридж со всеми вытекающими плюшками.

Вот видите, всё было не зря =)
Автор рад чтобы его поучили как надо, это нормально, коммунити этому и служит так-то)

На счёт OpenVPN согласен, его наличие «можно» поставить под вопрос.
А вот как Вы l2tp/ipsec будете пихать в bonding на mikrotik??? Это очень интересно.
Поясните для общего развития подробней что имели ввиду.
Извиняюсь, запамятовал порядок)
через L2tp/IPsec каналы кладется по одному тоннелю EoIP, получаем виртуальные ethernet, их включаем в bounding 802.3ad, с двух сторон получаем сбалансированные интерфейсы bounding, которые собсна и включены в мосты.
Так автор и реализовал l2tp\ipsec по верх него EoIP и получившиеся «eth» Запихнул в bonding.
А вот бриджи по верх этого делать уже лишнее, по крайней мере я бы не стал.
на ней поднял L2TP-сервер с включенным шифрованием IPsec;

поверх L2TP over IPsec создал два EoIP-туннеля;

EoIP-туннели агрегированы bonding-интерфейсом;



То есть Вы предлагаете увеличить кол-во туннелей до N-кол-ва и всё это бондить и бридживать??
Правильно понимаю?

В моем случае была необходимость сшивания нескольких, удаленных сетей в рамках одного адресного пространства, поэтому да, бридживать. В остальных случаях хватит и роутинга с натом.
Понял. Спасибо за ответ.
Проводили такие схемы ранее и отказались от такого. Например, в случае глюка одного из модемов или плохой связи вы долго будете искать виновного. В данном случае видно что сигнал хороший и не ощутили полную область веселья — все еще впереди.
Подобные схемы увеличивают latency особенно для voip трафика, не раз проводил эксперименты когда на удаленной точки по 3g,4g связи делал туннелирование и «старался увеличить скорость и надежность». Проведите замеры в конце концов на АТС или на ВКС сервере и поймете, что данные манипуляции только ухудшат связь. Тем более что можно поступать более административно — например правильно настроить QoS и разделить трафик по разным провайдерам для разных внутренних IP (мы явно знаем каким устройствам нужен приоритет).
По поводу переключения и т.п. — на уровне многих приложений уже есть reconnect в случае обрыва.
Отличная статья! Автору зачёт.
Интересная реализация агрегации каналов связи.
По поводу актуальности OpenVPN в данной статье считаю что всё нужно тестировать опытным путем.
в облаке создал «сервер агрегации» – виртуалку с CLOUD HOSTED ROUTER (CHR) на базе Router OS

Ладно, аппаратно Микротик — ок, но почему в виртуалке тотже Pfsense не пользовать? Умеет все выше перечисленное.
У самого настроено ovpn + ospf между Центром (2 ВАНа) и 14 Филиалами (по 1 ВАНу в каждом).
Время переключения между впн-каналами туда-обратно ~7 сек.
Вместо ovpn можно ipsec.
7 сек это пропасть в сравнении с тем, что в этой схеме вовсе ничего не теряется. pfsence не умеет L2 тунель (EoIP).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.