Author Topic: Балансировка трафика через несколько OpenVPN-теннелей.  (Read 7187 times)

0 Members and 1 Guest are viewing this topic.

Offline boombastic

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-0
Коллеги, есть  интересная задача.
общее описание:
Есть OpenVPN-сервер (linux), работающий с клиентами по схеме/топологии p2p
У сервера несколько Интернет-каналов/несколько "белых" IP.

Есть клиент OpenVPN (тоже linux), соединяющийся с ovpn-сервером.
У клиента так же два или три Интернет-канала
У "клиента" есть своя сеть /24, маршрутизируемая со стороны ovpn-сервера чз ovpn-соединение.

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


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

Проблема-то как со стороны ВПН-сервера.
Он будет видеть маршрут до локальной сети клиента через два туннеля, что вообщем-то не проблема.
Но , вот возвращать нужный трафик в нужный ВПН-туннель, согласно стандартным записям в таблице маршрутов (destination based routing) явно не

получится.

А хотелось бы.
Может быть кто-то уже озадачивался подобной проблемой балансировки трафика по двум или трём ovpn-туннелям.


Я при первом рассмотрении вижу решение "в лоб". Если делать PBR до на основании src_ip.
Скажем если надо диапазон адресов x.y.z.200 - 216 зарулить в тунель поверх резервного канала , то сгенерить специфический маршрут для этих адресов и средствами igp (rip,ospf и т.п.) заанонсировать его в сторону сервера.
Но вот если надо зарулить трафик не на основании src_ip а ,скажем, весь ftp-трафик через резервный туннель, то тут затрудняюсь что-либо придумать.

Offline Angel_of_Sorrow

  • Full Member
  • ***
  • Posts: 151
  • Karma: +5/-1
    • http://
А если поиграться с весом маршуртов ? или например с маркировкой пакетов ?

Offline werthk

  • Full Member
  • ***
  • Posts: 130
  • Karma: +3/-1
Если вы хотите балансировку в плане утилизации всех каналов вам надо смотреть возможность объединения в бонды

Поисковики даже что-то отдают по запросу openvpn bonding
« Last Edit: February 02, 2016, 10:17:16 by werthk »

Offline boombastic

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-0
Пока что копаю в сторону MPLS Traffic Engineering с попыткой прикрутить его к OpenVPN интерфейсам.
Простая и доступная статья , пусть даже не для линукса, есть здесь: http://wiki.mikrotik.com/wiki/Manual:Simple_TE (Extended Tunnel for VoIP)
Дальше буду копать аналоги для линукса, помнится mpls в ядре линукса уже реализовали.

вообщем задача из разряда - припаять деревяшку к стекляшке и запустить это всё в космос на воздушном шарике.
жуть как интересно.

Offline sparky

  • Newbie
  • *
  • Posts: 27
  • Karma: +0/-0
Олег, в стоковом ядре вряд ли скоро допилят поддержку MPLS, не говоря уже о MPLS-TE.
Есть коммерческие решения, например ZebOS XP http://www.ipinfusion.com/products/zebos-xp

Offline boombastic

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-0
Боюсь, в моём случае это не подойдёт
"костыль" надо реализовать как на впн-клиентах, так и на впн-серверах с балансировщиком.
« Last Edit: February 15, 2016, 13:47:11 by boombastic »

Offline sparky

  • Newbie
  • *
  • Posts: 27
  • Karma: +0/-0
Ну тогда, как вариант, попробуй OpenVswitch.
http://openvswitch.org/download/

Offline NiK

  • Full Member
  • ***
  • Posts: 199
  • Karma: +4/-3
    • http://
Для нормальной балансировки придется работать настройками с обеих сторон.
Поднимать дополнительный инстанс OSPF.
Маркировать трафик в фаерволе по классам, присваивая соответствующую метку роутинга
Роутить по двум таблицам, например, main+second.
На микротике всё добро идёт из коробки. На линуксе наверняка придётся что-то прикомпиливать.
Опять же, если определиться наверняка, надо ли гонять разные классы по разным vpn-каналам или достаточно "простой равномерной" балансировки с отказоустойчивостью - задача сильно упрощается.
« Last Edit: February 19, 2016, 13:16:43 by NiK »

Offline boombastic

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-0
Nik, нет там равномерной балансировки на ADSL/ETTH & 3G. Тут PBR будет, чистой воды. Но. задачу пока отложили т.к. сначала решено сделать новую систему управления клиентскими роутерами

Offline NiK

  • Full Member
  • ***
  • Posts: 199
  • Karma: +4/-3
    • http://
Если каналы ассиметричные, тогда даже проще. OSPF и разная цена интерфейсов
в зависимости от того, какой трафик преобладает входящий или исходящий. Например если исходящего меньше а входящего больше - исходящий загоняем в 3G, входящий в Adsl.

Пример для wireless просто адаптируется для туннелей.
http://wiki.mikrotik.com/wiki/Dual_Setup_with_OSPF
« Last Edit: February 21, 2016, 12:25:35 by NiK »

Offline boombastic

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-0
Nik, это не то. В примере - просто пример ассиметрии, отправка через один канал, а возврат трафика через другой.
Мне надо чтобы работало оба канала , чтобы резервный дублировал основной, но и в то же время не простаивал.
Quote
Хочется реализовать распределение нагрузки по резервным каналам подняв дополнительное ВПН-соединение.
Нужные классы трафика с стороны локальной сети клиента - заворачивать в нужное ВПН-соедение

Представь типовой офис, где идёт оплата и за основной канал связи (О.К) и за резервный канал связи (Р.К). Причём согласно логике OSPF - в какой-то конкретный момент времени, при нормальных условиях, работает именно О.К. Р.К формально простаивает т.к. он "на страховке". Но "для бизнеса" - абонентка за Р.К всё равно капает, пусть небольшая но идёт.
Теперь делаем "фокус" - таких офисов 10 тысяч   в каждом из них идёт оплата за Р.К. Надо "сделать так" чтобы он использовался, чтобы деньги не просто так платились.

Offline SinClaus

  • Sr. Member
  • ****
  • Posts: 453
  • Karma: +6/-2
Может просто RoundRobin сделать?
Самый страшный вирус называется юзер.

Offline boombastic

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-0
Не покатит.
VOIP, банковские платежи, онлайн-видео, а так же всё вида "интерактивный трафик" - через 3G работает отвратительно медленно

Offline NiK

  • Full Member
  • ***
  • Posts: 199
  • Karma: +4/-3
    • http://
Представь типовой офис, где идёт оплата и за основной канал связи (О.К) и за резервный канал связи (Р.К). Причём согласно логике OSPF - в какой-то конкретный момент времени, при нормальных условиях, работает именно О.К. Р.К формально простаивает т.к. он "на страховке". Но "для бизнеса" - абонентка за Р.К всё равно капает, пусть небольшая но идёт.
Теперь делаем "фокус" - таких офисов 10 тысяч   в каждом из них идёт оплата за Р.К. Надо "сделать так" чтобы он использовался, чтобы деньги не просто так платились.

Эээ, батенька, с таким подходом надо ИТ-директора менять. Поясню. Если О.К. полностью справляется с нагрузкой, то смысла балансировать через Р.К. нет. Задача Р.К. не в этом, а в принципиальном существовании связи на "всякий пожарный", и доведении внутреннего SLA до максимума.
Если гонять часть трафика в Р.К., получается, что имеющаяся за ёмкость О.К.  избыточна, и за неё идёт избыточная оплата. Тогда надо сокращать О.К. , что при явно низком качестве Р.К. - маразм.

Хреновый ИТ-директор, пойдет на поводу у горе-финансистов экономящих копейки с риском потерять больше... Ладно.
Не покатит.
VOIP, банковские платежи, онлайн-видео, а так же всё вида "интерактивный трафик" - через 3G работает отвратительно медленно
Поскольку качества Р.К. явно недостаточно для некоторых видов трафика - нужно создавать политику маршрутизации на основе типа трафика (например, protocol:ip:port).  Данный трафик пойдёт по другой таблице. Простейшее решение - маркировать в фаерволе. Bird вроде умел  две таблицы работать по OSPF. Либо VRF как-то удастся использовать.
В случае "падения" одного из каналов, просто две таблицы будут выглядеть одинаково.
« Last Edit: March 02, 2016, 00:48:08 by NiK »

Offline Unit

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1263
  • Karma: +9/-1
Эээ, батенька, с таким подходом надо ИТ-директора менять. Поясню. Если О.К. полностью справляется с нагрузкой, то смысла балансировать через Р.К. нет. Задача Р.К. не в этом, а в принципиальном существовании связи на "всякий пожарный", и доведении внутреннего SLA до максимума.
Если гонять часть трафика в Р.К., получается, что имеющаяся за ёмкость О.К.  избыточна, и за неё идёт избыточная оплата. Тогда надо сокращать О.К. , что при явно низком качестве Р.К. - маразм.

Хреновый ИТ-директор, пойдет на поводу у горе-финансистов экономящих копейки с риском потерять больше... Ладно.
Плюсую, очень грамотно развёрнуто и объяснено.

Offline boombastic

  • Hero Member
  • *****
  • Posts: 582
  • Karma: +9/-0
Nik, всё то касается технической части я описал ещё в первом сообщении, просто другими словами.
Как я и писал выше, при таком подходе остаётся "открытым" вопрос возврата трафика со стороны ВПН-сервера (и других сервер за бэкендами).
В случае использования VRF-lite мне придётся и на каждом vpn-srv и на балансировщике делать отдельную VRF и заполнять её каким-нибудь IGP.
Вопрос конечно реализуемый, но я хотел услышать *другие варианты*, а не то же самое.