Comments 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.
UFO just landed and posted this here
В конце предложу варианты решения для менее скромного бюджета – для крупных заказчиков.
крупные заказчики найдут ресурсы для организации надежной последней мили (хотя бы WiMax) и им, как правило, такие поделки очень портят качество канала. Там и с MTU не «поиграть» — 1520 байт хоть расшибись, а отдай. И Q-In-Q свой туда же не говоря про остальные параметры SLA.
Зачем столько туннелей? Почему нельзя было сделать разу EoIP+ipsec, поверх них бондинг и на этом всё?
EoIP не поднимается с серыми IP за натом.
Да, действительно. Но предназначение openVPN туннеля внутри бондинга всё равно остаётся неясным.
UFO just landed and posted this here
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, честно говоря, не пробовал. Спасибо, посмотрю, так сразу сложно сказать.
Интересная статья. Нужно попробовать на торговых точках будет.
UFO just landed and posted this here
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 роутерами.
Любую схему нужно тестировать. Я рассказал про схему, которая решила перечисленные проблемы в тех условиях, которые были у меня.
UFO just landed and posted this here
Хорошо, 2 L2tp+IPSEС как у автора, но городить поверх этого bonding. Зачем, когда можно сразу с L3 работать?
UFO just landed and posted this here
Я бы начал с того, что 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.
Sign up to leave a comment.
На коленке: агрегация VPN, или Надежная связь на ненадежных каналах