Под катом любопытного хабрачитателя ждет описание страданий людей, которые в свое время сэкономили денег на цисках с 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-машины).
