Pull to refresh

Программная маршрутизация: история переезда с hub-n-spoke (vyatta+openvpn) на fullmesh (mikrotik+tincvpn) — часть 1

Reading time 4 min
Views 24K

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


Предистория вопроса


Несколько лет назад, когда трава была зеленее, а %company_name% только начинала свою делятельность и имела 2 филиала,
было принято решение использовать изпользовать Vyatta Network OS в качестве единой платформы маршрутизации, а статические openvpn site-to-site тоннели — в качестве решения для VPN.

Одной из причиной такого решения была богатая возможность кастомизации ISR.
В качестве одной из мер по резервированию в каждый филал устанавливалось по 2 маршрутизатора.
«звездатая» топология при таком количестве пиров считалась оправданной.

В качестве hardware appliance предполагалось использовать
— полноценные сервера с esxi — для крупных инсталляций
— сервера с atom — для мелких.

ВНЕЗАПНО, за год количество филиалов увеличилось до 10, а еще за полтора — до 28.
Постоянный поток фирчеквестов от бизнеса провоцировал рост трафика и появление новых сетевых и application сервисов.
Некоторые из них оседали на виртуалках linux-маршрутизаторов, вместо отдельных серверов.

Функционала vyatta стало не хватать, большое количество пакетов сказывалось на общей стабильности и производительности сервисов.

Также, был ряд проблем с VPN.
1. На тот момент было около 100 статических тоннелей, терминировавихся в одну точку.
2. В перспективе было еще открытие 10 филиалов.

К тому же, openvpn в текущей реализации,
1. не позволяет создавать динамически генерируемые site-to-site тоннели.
2. не является многопоточным, что на процессорах маршрутизаторов с 1-2 аплинковыми тоннелями приводит к перегрузке 1-2 ядер (из 8-16 в нашем случае) шифрованием и приводит к веселым последствиям для трафика внутри тоннеля.
3. П.2 особенно характерен для маршрутизаторов, в процессорах которых отсутствовала поддержка AES-NI.

Можно было использовать gre+ipsec, что сняло бы проблемы с производительностью — но остались бы тоннели, сотни их.

Было очень грустно, хотелось обложиться теплыми цисками с аппаратным шифрованием и употребить dmvpn.
Или уже глобальный MPLS VPN.
Чтобы не мелочиться.

Надо было что-то делать (с)

— в филиалы стали 1-2х процессорные сервера с вкусным количеством мозга и esxi на борту
— маршрутизаторы были разуплотнены и все сторонние сервисы переехали на выделенные виртуальные машины с pure linux
— после некоторых поисков в качестве платформы маршрутизации была выбрана виртулизированная x86 routeros.
Опыт эксплуатации микротика к тому времени уже был, проблем с производительностью и стабильности на наших задачах под x86 не было.
На железных решениях, особенно — на RB7** и RB2011**- было и есть веселее

Потенциально, такое решение давало прирост функционала в области
— route redistribution
— pbr + vrf
— mpls
— pim
— qos
а также некорторых других.

Проблема была в том, что routeros (как и vyatta) не поддерживает многоточечные vpn.
Опять стало грустно, начали копать в сторону чисто линуксовых fullmesh-решений.

Отдельное, кстати, спасибо хабраюзеру ValdikSS за его статью.

Были рассмотрены: peervpn,tinc, campagnol, GVPE, Neorouter, OpenNHRP, Cloudvpn, N2N
В итоге остановились на tincvpn, как на компромиссном решении.
Еще очень понравился gvpe экзотическими методами инкапсуляции, но он не позволял указать несколько IP (от разных ISP) для remote peer.

Что обидно, tinc был тоже однопоточным.
В качестве решения был использован грязный хак:
1. между каждыми двумя членами mesh поднимается не по 1, а по N тоннелей, объединяемых потом в bond-интерфейс с балансировкой исходящего трафика.

2. в результате, получаем уже N процессов, которые уже можно распределить между разными ядрами.

При использовании указанной схемы, в лабе с
— 8 tinc-интерфейсами, агреггироваными в один bond по указанной схеме
— принудительной привязкой процессов к разным ядрам
— 1 x xeon 54**, 55** (процессоры старого поколения без поддержки aes-ni)
— aes128/sha1,
— udp в качестве транспортного протокола.
— без использования qos как изнутри так и снаружи тоннеля.

Производительность vpn составляла около 550-600 mbps на гигабитном канале.
Мы были спасены.

Что получилось:
1. Итоговое решение получило рабочее название «vpn-пара».
2. Состоит из двух виртуальных машин, расположенных на одном esxi-хосте и объединенных виртуальным интерфейсом.
1 — routeros, который занимается исключительно вопросами маршрутизации
2 — pure linux с вылизаным и слегка допилиенным tinc.
Выполняет роль vpn-моста.
Конфигурация tinc — аналогично лабораторной, при этом bond-интерфейс сбриджен с виртуальным линком на микротик.
В результате, у всех маршрутизаторов общий L2, можно поднимать ospf и наслаждаться.
3. В каждом филиале по 2 vpn-пары.

...to be continued...

Примечания


1. В принципе, интегрировать tinc можно и в vyatta, по этому поводу даже был написан патч (для варианта с 1 интерфейсом)
Но прогнозировать поведение такой связки в аварийной ситуации (или после обновления платформы) с кастомным патчем до конца сложно и для большой сети такие эксперименты нежелательны.

2. Рассматривался также вариант «матрешка».
Он имел 2 направления:
— покупка аппаратного x86 микротика и поддержка linux-vm с vpn-мостом средствами встроенной виртуализации (KVM).
не взлетело из-за низкой производительности.

— nested virtualization (esxi -> routeros -> kvm -> linux).
не взлетело по тем же причинам, из за отсутствия поддержки эмуляции VT-X/EPT в esxi 5.1 (нужно для запуска kvm-машины).
Tags:
Hubs:
+5
Comments 14
Comments Comments 14

Articles