Full mesh vpn что это

Построение Full-Mesh VPN-сети с использованием fastd, tinc, VpnCloud и тестирование производительности

Привет, Хабр! Меня зовут Олег, я архитектор клиентских решений в Selectel. Недавно мы столкнулись с интересным клиентским кейсом при создании Full-Mesh сети. Расскажу, как пришлось тестировать VPN-сервисы, чтобы найти оптимальное решение.

Все результаты собрал в сводной таблице, чтобы наглядно показать разницу и аргументировать выбор.

К нам обратился клиент с задачей по переносу данных с арендованных выделенных серверов одного популярного в России поставщика услуг из Германии. На то было две причины:

• Невозможность простой и быстрой оплаты услуг, поскольку привязанная карта российского банка перестала работать.
• Защита от возможной эскалации санкционного давления (то есть полный запрет работы).

C чем мы столкнулись

Компания арендовала в Германии такую инфраструктуру:

• два сервера-гипервизора на базе Qemu/KVM с управлением через libvirtd,
• два сервера c Docker-контейнерами для разработчиков и их заказной CRM/ERP-системой,
• несколько виртуальных машин на Linux и Windows Server 2019.

Сначала мы изучили текущее клиентское решение и предложили на его основе свою схему миграции, которая бережно относилась к текущей IT-инфраструктуре и при этом не теряла в отказоустойчивости.

Далее мы занялись обеспечением сетевой связности на втором уровне стека протоколов TCP/IP. Так мы смогли обеспечить клиенту «бесшовный» перенос виртуальных машин и сохранить IP-адреса. Чтобы оптимизировать бюджет, клиент выбрал серверы линейки Chipcore, в которых отсутствует «приватная сеть».

На этапе миграции остановились на следующей организации сетевой топологии. Так мы обеспечили единую L2-связность между дата-центром Selectel и зарубежным ЦОД:

Потенциальные кандидаты

Дело осталось за малым — подобрать VPN, который прост в настройке, поддерживает L2, полносвязную топологию и использует быстрые, криптостойкие алгоритмы шифрования.

Вариант с Wireguard был отброшен сразу: он не работает по L2, только по L3, хотя продукт достойный.

OpenVPN — в данном случае не лучший выбор, так как имеет клиент-серверную архитектуру. В случае возникновения проблем или при регламентном обслуживании сервера связность на L2 потеряется. Нам не хотелось создавать точку отказа.

Во время миграции можно было бы использовать OpenVPN, но хотелось сразу подготовить решение, которое не нужно дорабатывать.

Рассматривались следующие варианты:

• fastd,
• VpnCloud,
• Tinc.

К сожалению, там нет даже упоминания fastd, который использовался в проекте.

Выбирать, основываясь на субъективном мнении пользователей и разработчиков, не хотелось, поэтому решили провести лабораторное тестирование VPN-систем и составить свое предвзятое мнение ��.

Критерии, по которым оценивались кандидаты:

• скорость передачи данных через туннель,
• стабильность работы,
• простота и удобство настройки,
• кроссплатформенность, наличие готовых пакетов под различные дистрибутивы Linux,
• документация.

Важное лирическое отступление по MTU

При использовании VPN мы имеем дело с инкапсуляцией пакетов, поэтому важно правильно выставить значение MTU. Новый туннель добавляет дополнительные заголовки к пакету и снижает возможное количество передаваемых полезных данных (payload). Накладные расходы зависят как от типа туннельного интерфейса, так и от используемых алгоритмов шифрования данных.
Например, для нашего проекта получаем:

• Базовый MTU — 1 500 байт (стандарт для IEEE 802.3 Ethernet).
• TAP-интерфейс — дополнительно 28+14=42 байта.
• IPv4 дополнительных байт не добавляет. Если бы использовался IPv6, то общий MTU уменьшился еще на 20 байт.
• Шифрование — еще 24 байта.

Что это означает на практике:

• При создании сетевого моста Linux или программного коммутатора (если вы захотите использовать Open vSwitch), в который предполагается добавить VPN-интерфейс, то MTU моста/свитча, как и MTU всех подключенных к нему Ethernet и виртуальных интерфейсов должен быть одинаковый, но при этом меньше или равен 1 434 байтам.
• Нужно убедиться, что в ОС на виртуальной машине на сетевом адаптере также выставлен правильный MTU, например, для ВМ с ОС Windows:

• Во избежании проблем с path mtu discovery blackhole на хостах Qemu/KVM нужно создать правило netfilter. Например, при использовании iptables:
  sudo iptables -t mangle -A FORWARD -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —clamp-mss-to-pmtu

Тестирование

1. На нашей облачной платформе создаются три виртуальные машины в разных зонах доступности (и регионах). При этом используются разные дистрибутивы Linux (rpm-based и deb-based).
2. Один раз запускаем iperf для измерения скорости передачи данных между машинами без VPN, фиксируем результат.
3. Средствами пакетного менеджера из репозиториев устанавливаем тестируемый VPN на все серверы и настраиваем его для взаимодействия с другими пирами. Также настраиваем автоматический старт при перезагрузке машины. Если позволяет ПО, выставляем либо самый быстрый, либо рекомендуемый разработчиком алгоритм шифрования трафика. Важно: VpnCloud не позволяет задать алгоритм шифрования вручную — только автоматически после запуска внутреннего бенчмарка.
4. Запускаем iperf на 30 минут, фиксируем скорость передачи данных, задержки, затем заносим данные в таблицу.
5. Последовательно осуществляем остановку и запуск VPN-сервиса на всех виртуальных машинах и фиксируем прохождение трафика между остальными включенными пирами (убеждаемся, что VPN действительно полносвязный).
6. После теста пакет с машины удаляется.
7. Оцениваем VPN-сервисы по объявленным выше критериям, выставляя места от 1 до 3.

Переходим к тестированию.

fastd

По установке все тривиально. Для RHEL-based дистрибутивов собранный пакет присутствует в EPEL, для Ubuntu — в universe.

Для AlmaLinux и CentOS убеждаемся, что EPEL задействован и ставим пакет:

Для Ubuntu устанавливаем штатно:

Конфигурирование идентично для всех дистрибутивов в тесте. Смотрим на unit, поставляемый с пакетом:

Создаем каталог и конфигурационный файл в нем:

Генерируем публичный и приватный ключ для каждой машины:

Вывод будет иметь следующий вид (ключи в production-конфигурациях не используются):

Содержимое раздела с пирами уникально на каждой виртуальной машине. У каждого будет свой secret и скрипты on up/down, а также закомментирован peer, в котором фигурирует непосредственно хост. Для примера здесь приведена конфигурация fastd на peer-01:

Запускаем демон и задействуем его при включении сервера:

После подключения всех пиров в логах будут следующие строки:

Устанавливаем iperf. Для RHEL-based дистрибутивов:

Для Debian соответственно:

Запускаем утилиту в режиме сервера на одном из пиров, на втором — в режиме клиента и замеряем скорость соединения без использования туннеля:

Далее повторяем измерения, но уже через VPN-туннель:

VpnCloud

Разработчик предоставляет готовые пакеты, которые доступны для скачивания и установки в разделе releases на GitHub. Для Debian/Ubuntu также можно воспользоваться репозиторием.

Для установки последней стабильной версии в AlmaLinux и CentOS выполняем:

Для Ubuntu подключаем репозиторий и устанавливаем:

Далее для конфигурирования можно воспользоваться мастером, который предоставляет TUI, работающий в трех режимах: базовом, продвинутом и экспертном. Запускается мастер следующим образом:

Вводим запрашиваемые данные и после его успешного выполнения по пути /etc/vpncloud/$.net создастся YAML-файл с настройками. Я мастером пользоваться не стал, изучил man vpncloud, пример из /etc/vpncloud/example.net.disabled и сделал конфигурацию самостоятельно, предварительно сгенерировав ключи. На каждом из peer запускаем:

Приведенные ключи в production-конфигурациях не используются.

Вносим ключи в конфигурацию на каждой виртуальной машине, не забываем добавить публичную часть ключа в доверенные на других серверах.

Как и для предыдущего участника теста, изучаем Unit systemd пакета:

Запускаем его и задействуем старт при включении сервера:

Теперь все готово для замера скорости в iperf.

Результат идентичен показателям fastd в пределах погрешности.

Tinc — весьма популярный проект. Готовые бинарные пакеты присутствуют, пожалуй, во всех дистрибутивах Linux и BSD. Для RHEL-based дистрибутивов собранный пакет присутствует в EPEL, для Ubuntu — в universe.

Для AlmaLinux и CentOS убеждаемся, что EPEL задействован и ставим пакет:

Для Ubuntu/Debian устанавливаем с помощью пакетного менеджера APT:

Посмотрим, какой systemd-юнит нам предлагает мейнтейнер пакета:

Создаем каталог и конфигурационный файл в нем:

Создадим конфигурацию. Для примера здесь приведена конфигурация Tinc на peer-01:
sudo cat /etc/tinc/vpntest/tinc.conf

Затем в папке /etc/tinc/vpntest/hosts нужно создать конфигурационные файлы для других участников mesh-сети с сгенерированными публичными ключами (даны для примера, в production не используются и не должны использоваться).

Создаем скрипт, который будет выполняться при запуске tincd:
sudo touch /etc/tinc/vpntest/tinc-up && sudo chmod +x /etc/tinc/vpntest/tinc-up
со следующим содержимым (пример: опять же, для peer-01, для peer-02 и peer-03 вносятся соответствующие сетевой схеме адреса):

Запускаем сервис и проверяем:

Тестируем задержки и скорость передачи данных через туннель:

Скорость у Tinc заметно «просела», а задержки оказались выше.

Результаты

Скорость передачи данных. Первое место между собой поделили VpnCloud и fastd, Tinc — на втором месте.

Стабильность работы. Все программы работали стабильно: ошибок, аварийных завершений и утечек памяти во время тестирования не наблюдалось. Все участники теста разделили первое (или последнее третье, если угодно) место.

Простота, удобство настройки. Этот пункт для оценки достаточно субъективный. Мне показалось, что fastd гибче в настройке, так как позволяет создать как монолитную конфигурацию, так и «разнести» по отдельным файлам.

Также для fastd был создан Ansible Playbook для его массового развертывания и настройки. Если эта тема интересна — могу написать отдельную статью или добавить ссылку в GitHub gists без подробного разбора.

Из плюсов — VpnCloud поддерживает beaconing. Это позволяет облегчить конфигурирование, но я его не использовал ни в тестировании, ни в production, так как ни в одном из случаев не было большого количества узлов.

Кроссплатформенность, наличие готовых пакетов. Как уже было упомянуто, пакеты собраны для всех распространенных дистрибутивов Linux. Но что касается других платформ (Windows, MacOS X, BSD), то тут Tinc — безусловный лидер. На втором месте — fastd (без поддержки Windows), а на третьем — VpnCloud, который на данный момент поддерживает только Linux.

Документация. Выскажу субъективное мнение. Считаю, что документация fastd лучше структурирована, используется Read the Docs со всеми вытекающими. Безусловно, стоит отметить VpnCloud. Документация Tinc хороша, если рассматривать ее с точки зрения принципа KISS: вся нужная информация в одном man-файле. Отдаю приз fastd, а второе место делят VpnCloud и Tinc.

Место	ПО	Версия	ЯП	Поддержка ОС Linux/Windows/BSD	Транспортные протоколы	Выбор алгоритма шифрования данных	Алгоритм(-ы) шифрования передаваемых данных
1	fastd	v22	C	да/нет/да	UDP	вручную	AES-256, AES-128, ChaCha20
2	VpnCloud	2.3.0	Rust	да/нет/нет	UDP	авто	AES-128-CTR, Salsa20, Salsa2012
3	Tinc	1.0.36	C	да/да/да	UDP+TCP	вручную	AES-256 (все поддерживаемые OpenSSL)

Что в итоге

По результатам тестирования был выбран fastd, который и был использован в проекте.

Демоны fastd были сконфигурированы на всех серверах и при старте добавлялись в уже работающие мосты с предварительно настроенным MTU 1 400 байт, которые использует libvirtd, настроена сеть на серверах с Docker. После чего была осуществлена миграция виртуальных машин и persistent-данных для контейнеров. В эксплуатации новая информационная система находится с апреля текущего года и проблем с сетью и стабильностью работы мы не наблюдаем. Стоит отметить, что такое решение можно при необходимости использовать и в Proxmox VE.

Нам удалось предоставить клиенту кастомное решение, которое полностью закрывало его потребности во время миграции. Для этого пришлось проделать исследование и провести ряд тестов, что положительно сказалось на результате и комфорте эксплуатации проекта.

Mesh технологии

Беспроводные интернет-технологии развиваются стремительными темпами, и на сегодняшний день Wi-Fi имеется практически в каждом доме. Некоторые устройства появились на отечественном рынке относительно недавно, но уже сумели обрести огромную популярность. К таким относятся системы Mesh.

Если у пользователя дома имеется Wi-Fi сеть, но она не охватывает все зоны, стоит обратить внимание на данную инновационную разработку. Можно использовать обычные удлинители, но у них есть недостатки, например, возникновение сложностей в процессе настройки. Устройства подключаются и настраиваются за несколько секунд, а дальнейшее управление невероятно простое и понятное на интуитивном уровне.

Что являет собой Mesh разработка?

Если перевести слово «mesh» с английского языка, оно будет иметь несколько значений, одно из которых это – «ячейка». Из перевода приблизительно понятно, что такое Mesh. Подобная Wi-Fi схема должна состоять из нескольких модулей, каждый из которых представляет отдельное устройство. Она может выглядеть как стандартный роутер, однако, как правило, разработчики позаботились, чтобы модули нового типа отличались улучшенным дизайном. Приборы продаются в различных комплектациях, у пользователя есть возможность приобрести набор из одного или нескольких модулей. Все компоненты являются одинаковыми, у них нет центрального устройства.

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

Возможно подключить интернет-кабель к любому модулю Меш сети, и он будет делиться данными с другими устройствами, подключенными к схеме. То есть интернет необходимо подсоединить к одному роутеру, а к остальным подключается только питание.

Что такое Меш система? Чем она отличается от обычного маршрутизирующего оборудования? Основная суть разработки – это покрытие стабильным сигналом большой площади. Раньше для этих целей использовался мощный и дорогой роутер, а если сигнал не охватывал всю территорию, устанавливались дополнительные репитеры. Такая разработка имела несколько недостатков. Во-первых, комплект оборудования требовал немалых финансовых затрат, во-вторых, каждый репитер снижал скорость, получаемую от первоначального передатчика, в-третьих, их приходилось настраивать отдельно. Компоненты Меш не нужно настраивать по отдельности, они работают с одинаковыми параметрами и автоматически подхватывают сигнал.

По сравнению со стандартным роутером, пользователь имеет дело с так называемым «бесшовным» роумингом. При перемещении по дому гаджет сам будет выбирать ближайшую точку и подключаться к ней без разрыва соединения.

Особенности и преимущества систем

Еще несколько лет назад подобные технологии были доступны лишь немногим людям из-за высокой стоимости. Сегодня ведущие производители налаживают массовое производство оборудования, благодаря чему оно становится все более доступным для конечного потребителя.

Выделяются следующие достоинства и особенности устройств Wi-Fi поддерживающих технологию Mesh:

1. Расширенный радиус действия. Модульная система позволяет ловить Wi-Fi даже в самых дальних помещениях. Расширить сеть можно в любой момент, приобретя еще один модуль и подключив его к первому в одной из зон со стабильным сигналом. В случае «вылета» из сети одного из устройств соединение восстанавливается автоматически, используя прочие компоненты.
2. Бесшовная сеть. В зоне действия подключенных приборов создается лишь одна Wi-Fi сеть. При передвижении по дому гаджет подключается к роутеру с более мощным сигналом, при этом не будет наблюдаться каких-либо обрывов или отключений.
3. Стабильная работа системы и высокая скорость интернета. Современные устройства, работающие с технологией Меш, могут работать в двух и даже трех диапазонах. Они поддерживают стандарт AC и раздают Wi-Fi на частотном диапазоне в 2,4 ГГц и 5 ГГц. В случае с усилителями беспроводной схемы наблюдается постоянное падение скорости, с новой технологией эта проблема легко решается, главное, чтобы модули были установлены в зоне с хорошим и стабильным сигналом. Для ускорения работы могут быть использованы и другие разработки, например, MU-MIMO.

Пользователи, которые знают, что это – Меш сети, уже сумели оценить их преимущества и удобство в использовании. Настройка оборудования выполняется за несколько минут с помощью мобильного приложения. Независимо от производителя, принцип работы всех модульных систем аналогичный. Небольшие отличия могут наблюдаться в технических характеристиках и функциональных возможностях. Стандартные комплекты обладают всеми необходимыми функциями, такими как родительский контроль, защита сети, антивирусные программы, обновление ПО и т.д.

Корпоративная сеть по технологии Mesh

Еще совсем недавно никто бы не мог подумать, что оборудование Wi-Fi можно будет использовать для построения корпоративной сети предприятия. Современные устройства претерпели значительные изменения, они обладают более высокой мощностью и большим количеством функциональных возможностей. Старые разработки обладали низкой пропускной способностью, для них отсутствовали надежные механизмы от взлома, а установка Wi-Fi роутеров не избавляла от необходимости протягивать провода.

Сегодня ситуация изменилась во многом благодаря такой технологии, как Mekrotik Mesh. Что это такое, знает пока небольшое количество корпоративных пользователей, но они уже по достоинству оценили возможности системы. Новые разработки упрощают выполнение пуско-наладочных работ. С их помощью экономятся средства, которые могли быть потрачены на радиопланирование. Меш активно используют не только на предприятиях и в офисных зданиях, она удобна для использования и в парках, на открытых площадках, стадионах и прочих объектах.

Современные профессиональные Wi-Fi решения позволяют добиться равномерного покрытия даже на складских помещениях с большой площадью. А что такое Full Mesh VPN? При работе с серверами важным критерием является не только скорость передачи данных, но и уровень защиты и безопасности. Там, где стандартные технологии не могут обеспечить конфиденциальность передаваемых и получаемых данных, применяются новые разработки. Full Mesh VPN нередко используются и для игровых серверов. Пользователи создают закрытые чаты, через которые можно отправлять файлы или голосовые сообщения.

Может ли Softether VPN Full-Mesh

Классическая схема, есть три филиала в каждом по VPN серверу. Можно ли настроить SoftEther VPN таким образом чтобы каждый филиал общался c каждым напрямую(Full-Mesh)? Если да то в какую сторону копать?

Всмысле чтобы он туннели строил сам, без настройки? Аля DMVPN цыскин?

Нет. Мне нужно чтобы трафик шел по кратчайшему маршруту.

Скажем физически имеются три филиала с такими настройками. 1 филиал подсеть 192.168.1.0/24 GW 192.168.1.1 2 филиал подсеть 192.168.2.0/24 GW 192.168.2.1 3 филиал подсеть 192.168.3.0/24 GW 192.168.3.1

Я могу настроить примитивные маршруты

1 Филиал 192.168.2.0/24 -> Внешний IP Филиала 2 192.168.3.0/24 -> Внешний IP Филиала 3

2 Филиал 192.168.1.0/24 -> Внешний IP Филиала 1 192.168.3.0/24 -> Внешний IP Филиала 3

3 Филиал 192.168.1.0/24 -> Внешний IP Филиала 1 192.168.2.0/24 -> Внешний IP Филиала 2

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

С VPN мы получаем этакий виртуальный свич к которому подключены все узлы сети, но трафик физически сначала идет на главный VPN сервер, а только потом на узел назначения. Если VPN сервер упадет, упадет весь VPN.

Мне нужно чтобы при VPN схеме трафик направлялся сразу в узел назначения, и чтобы при падении VPN сервера фактически работоспособность сети не падала.

Эту фичу называют поразному P2P VPN, Full-Mesh VPN. Знаю что такое умеет проприетарный Hamachi, пробовал tinc но он не стабилен.

Full Mesh VPN Topology

Full-Mesh is a configuration option for the VPN Topology configuration item. The VPN topology determines whether access controls are in use or not. When VPN topology is set to ‘Full Mesh,’ unrestricted access between all Users, Networks, and Hosts is active. This is the default setting.

Who should use this?

The Administrator uses this to control the access between VPN endpoints.

Show me how to configure it:

When should I make use of this?

VPN topology is set to ‘Full Mesh,’ when the purpose of the VPN is to provide full connectivity without access controls between all VPN endpoints.