Комментарии 51
Интересная бюджетная схема.
С центральным сервером все понятно. Но два LTE-интерфейса на mikrotik — вы использовали плату с двумя и выше minipcie слотами? Какие модемы? Интересно конкретное оборудование с точки зрения надежности.
С центральным сервером все понятно. Но два 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 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 умеет выдавать виртуальные адреса
Можно использовать IPsec в туннельном режиме и поверх него уже GRE, IPIP, XXoIP и вообще что угодно. То есть, L2TP из связки можно исключить.
Зачем внутри шифрованного L2TP шифрованный OpenVPN?
Зачем вообще OpenVPN в этой схеме? Судя по статье, интерфейс ovpn_over_bonding1 используется только для маршрутизации, но ведь уже есть интерфейс bonding1 и для маршрутизации можно использовать его.
Зачем вообще OpenVPN в этой схеме? Судя по статье, интерфейс ovpn_over_bonding1 используется только для маршрутизации, но ведь уже есть интерфейс bonding1 и для маршрутизации можно использовать его.
OpenVPN поверх bonding используется не для маршрутизации, без него работать не будет, проверено.
L2TP или другие туннели необходимы для связки, внутри которых поднимается L2-туннели EoIP. Агрегировать можно OpenVPN или EoIP — в bonding можно добавить только эти туннели.
BCP, честно говоря, не пробовал. Спасибо, посмотрю, так сразу сложно сказать.
L2TP или другие туннели необходимы для связки, внутри которых поднимается L2-туннели EoIP. Агрегировать можно OpenVPN или EoIP — в bonding можно добавить только эти туннели.
BCP, честно говоря, не пробовал. Спасибо, посмотрю, так сразу сложно сказать.
Интересная статья. Нужно попробовать на торговых точках будет.
НЛО прилетело и опубликовало эту надпись здесь
Brodcast даст ширину канала как у худшего из каналов, но латентность как у лучшего из каналов.
Плюс дублирование даёт хорошую защиту от потерь пакетов, не 100%, но вероятность потери пакета сразу на двух каналах значительно ниже.
Поэтому при агрегации LTE, когда важнее получить более стабильный канал с шириной «как повезёт», лучше подходит broadcast.
Active-backup лучше подходит при агрегации стабильных каналов с разной шириной.
Плюс дублирование даёт хорошую защиту от потерь пакетов, не 100%, но вероятность потери пакета сразу на двух каналах значительно ниже.
Поэтому при агрегации LTE, когда важнее получить более стабильный канал с шириной «как повезёт», лучше подходит broadcast.
Active-backup лучше подходит при агрегации стабильных каналов с разной шириной.
1) Возможно, нужно проверить.
2) Shrim ответил.
2) Shrim ответил.
А почему 3des? А не AES256?
Спасибо, кстати, за статью вообще.
А сравнивали разницу в скорости между «просто мобильный оператор связи» и ваш вариант? Хотя бы для интереса?
Зачем так сложно? шифрование — нужно ли вообще?
и зачем бондинг? почему не 2 GRE туннеля и не банальная настройка OSPF с BFD, классическая схема 2 канала между 2 роутерами.
и зачем бондинг? почему не 2 GRE туннеля и не банальная настройка OSPF с BFD, классическая схема 2 канала между 2 роутерами.
Любую схему нужно тестировать. Я рассказал про схему, которая решила перечисленные проблемы в тех условиях, которые были у меня.
НЛО прилетело и опубликовало эту надпись здесь
Хорошо, 2 L2tp+IPSEС как у автора, но городить поверх этого bonding. Зачем, когда можно сразу с L3 работать?
НЛО прилетело и опубликовало эту надпись здесь
Я бы начал с того, что DPD у IKEv2 поставил секунд 5 и если схема позволяет использовал бы статику. Упал интерфейс туннельный, не стало маршрутов через него (у EoIP также есть keepalive интервал и пакеты также пропадут). если нужна прям динамика, то ospf на туннельных интерфейсах, лучше не в области 0. но конечно, надо пробовать.
Сам себя поправлю, пока никто не заметил ) bfd на LTE эт я махнул конечно.
В данной схеме 2 GRE с keepalive внутри + статика тоже скорее всего сгодятся.
В данной схеме 2 GRE с keepalive внутри + статика тоже скорее всего сгодятся.
Зачем, если есть очень бюджетные и удобные Fortigate? Там и человеческая динамическая маршрутизация с любым вкусом, и SDWAN, и FEC, и агрегация туннелей и многое-многое-многое другое. Всё с отличным WUI/CLI.
Что ж, впервые за 10 лет я всё-таки зарегался на Хабре, чтобы оставить комментарий к этой инструкции.
Дорогой, автор, направление мысли исключительно правильное. Но почему в качестве тоннеля внутри уже шифрованного L2TP/IPsec ты выбрал ещё один l2 туннель с шифрованием OpenVPN?
Проблему гарантированного доступа давно решаю при помощи двух/трёх/и даже четырех тоннелей L2tp/IPsec, сагрегированных при помощи bounding и пропущенного через виртуальный интерфейс EoIP тоннеля. Более того, созданный интерфейс воспринимается микротиком как обычный Ethernet и позволяет безболезненно включить его в бридж со всеми вытекающими плюшками.
Вот видите, всё было не зря =)
Автор рад чтобы его поучили как надо, это нормально, коммунити этому и служит так-то)
На счёт OpenVPN согласен, его наличие «можно» поставить под вопрос.
А вот как Вы l2tp/ipsec будете пихать в bonding на mikrotik??? Это очень интересно.
Поясните для общего развития подробней что имели ввиду.
А вот как Вы l2tp/ipsec будете пихать в bonding на mikrotik??? Это очень интересно.
Поясните для общего развития подробней что имели ввиду.
Извиняюсь, запамятовал порядок)
через L2tp/IPsec каналы кладется по одному тоннелю EoIP, получаем виртуальные ethernet, их включаем в bounding 802.3ad, с двух сторон получаем сбалансированные интерфейсы bounding, которые собсна и включены в мосты.
через L2tp/IPsec каналы кладется по одному тоннелю EoIP, получаем виртуальные ethernet, их включаем в bounding 802.3ad, с двух сторон получаем сбалансированные интерфейсы bounding, которые собсна и включены в мосты.
Так автор и реализовал l2tp\ipsec по верх него EoIP и получившиеся «eth» Запихнул в bonding.
А вот бриджи по верх этого делать уже лишнее, по крайней мере я бы не стал.
То есть Вы предлагаете увеличить кол-во туннелей до N-кол-ва и всё это бондить и бридживать??
Правильно понимаю?
А вот бриджи по верх этого делать уже лишнее, по крайней мере я бы не стал.
на ней поднял L2TP-сервер с включенным шифрованием IPsec;
поверх L2TP over IPsec создал два EoIP-туннеля;
EoIP-туннели агрегированы bonding-интерфейсом;
То есть Вы предлагаете увеличить кол-во туннелей до N-кол-ва и всё это бондить и бридживать??
Правильно понимаю?
Проводили такие схемы ранее и отказались от такого. Например, в случае глюка одного из модемов или плохой связи вы долго будете искать виновного. В данном случае видно что сигнал хороший и не ощутили полную область веселья — все еще впереди.
Подобные схемы увеличивают latency особенно для voip трафика, не раз проводил эксперименты когда на удаленной точки по 3g,4g связи делал туннелирование и «старался увеличить скорость и надежность». Проведите замеры в конце концов на АТС или на ВКС сервере и поймете, что данные манипуляции только ухудшат связь. Тем более что можно поступать более административно — например правильно настроить QoS и разделить трафик по разным провайдерам для разных внутренних IP (мы явно знаем каким устройствам нужен приоритет).
По поводу переключения и т.п. — на уровне многих приложений уже есть reconnect в случае обрыва.
Подобные схемы увеличивают latency особенно для voip трафика, не раз проводил эксперименты когда на удаленной точки по 3g,4g связи делал туннелирование и «старался увеличить скорость и надежность». Проведите замеры в конце концов на АТС или на ВКС сервере и поймете, что данные манипуляции только ухудшат связь. Тем более что можно поступать более административно — например правильно настроить QoS и разделить трафик по разным провайдерам для разных внутренних IP (мы явно знаем каким устройствам нужен приоритет).
По поводу переключения и т.п. — на уровне многих приложений уже есть reconnect в случае обрыва.
Отличная статья! Автору зачёт.
Интересная реализация агрегации каналов связи.
По поводу актуальности OpenVPN в данной статье считаю что всё нужно тестировать опытным путем.
Интересная реализация агрегации каналов связи.
По поводу актуальности OpenVPN в данной статье считаю что всё нужно тестировать опытным путем.
в облаке создал «сервер агрегации» – виртуалку с CLOUD HOSTED ROUTER (CHR) на базе Router OS
Ладно, аппаратно Микротик — ок, но почему в виртуалке тотже Pfsense не пользовать? Умеет все выше перечисленное.
У самого настроено ovpn + ospf между Центром (2 ВАНа) и 14 Филиалами (по 1 ВАНу в каждом).
Время переключения между впн-каналами туда-обратно ~7 сек.
Вместо ovpn можно ipsec.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На коленке: агрегация VPN, или Надежная связь на ненадежных каналах