Что такое Veeam Powered Network
Veeam Powered Network (Veeam PN) – это технология, используемая при работе Veeam Recovery to Microsoft Azure (восстановлении виртуальной машины в облако Microsoft Azure). С помощью Veeam PN устанавливается VPN-соединение между on-premises сетью и сетью Microsoft Azure.
Используемые технологии – WireGuard и OpenVPN. Настройка и управление VPN выполняются через веб-интерфейс.
Veeam PN может быть полезен, например, в таких сценариях:
- Обеспечение доступа к корпоративной сети через сеть Microsoft Azure для удаленных пользователей.
- Создание VPN-соединения типа site-to-site между офисами компании и сетью Microsoft Azure, к которой подключены виртуальные машины, восстановленные в облако Microsoft Azure.
- Создание VPN-соединения типа point-to-site между удаленными компьютерами и сетью Microsoft Azure, к которой подключены виртуальные машины, восстановленные в облако Microsoft Azure.
За подробностями добро пожаловать под кат.
Пример использования
В одном из вышеназванных сценариев (site-to-site) весь VPN-траффик контролируется с помощью компонентов Veeam: network hub (сетевой хаб) и site gateways (шлюзы на сайтах).
Сеть VPN, которая выстраивается таким образом (через Veeam PN), имеет топологию «звезда». Весь траффик в сети VPN всегда направляется через сетевой хаб.
При всём при этом вам не нужно кропотливо настраивать VPN на множестве машин, работающих на удаленных сайтах — достаточно установить и наладить Veeam PN. Профит!
Допустим, вы хотите добавить к сети VPN 3 удаленных сети: 2 сети on-premises и одну облачную сеть в Microsoft Azure. Для такой конфигурации вам нужно развернуть сетевой хаб в облаке Microsoft Azure и по одному шлюзу в каждой из on-premises сетей. Весь траффик будет направляться через сетевой хаб в облаке.
Еще пример
В другом сценарии (site-to-site) сетевой хаб настраивается в той сети, куда нужно обеспечить доступ пользователей (это может быть как облачная сеть, так и сеть on-premises).
Чтобы дать удаленному пользователю доступ к сети VPN, организованной с помощью решения Veeam PN, нужно настроить OpenVPN на пользовательской машине. Для связи с машиной в сети VPN этот пользователь должен подключиться к сетевому хабу, а тот уже направит траффик к нужным ресурсам в сети VPN.
Отметим, что при этом нет необходимости настраивать публично доступный шлюз, публичный IP-адрес или имя DNS.
На картинке данный сценарий будет выглядеть так:
Подробнейшее руководство и описание разных сценариев использования для Veeam PN доступно тут (на англ.языке).
После знакомства с этим решением пользователям, конечно, захотелось чего-то новенького в функциональных возможностях. И вот что было реализовано в версии 2.0:
- Переход к технологии WireGuard
- Соответственно, улучшенная безопасность и повышенная производительность
- Возможность выбора протокола (TCP или UDP)
- Упрощенная процедура развертывания
Переход к технологии WireGuard
В новейшей версии решения Veeam PN мы перешли от использования OpenVPN к WireGuard, поскольку именно WireGuard постепенно становится новым стандартом в индустрии VPN-технологий.
WireGuard хорошо масштабируется, поддерживает достаточно высокий уровень безопасности с улучшенным шифрованием, превосходит OpenVPN по пропускной способности.
Разработчикам WireGuard удалось добиться таких результатов благодаря задействованию непосредственно ядра (kernel) и написанию кода “с нуля”, причем со значительно меньшим количеством строк кода (в WireGuard всего 4,000 строк против 600, 000 в OpenVPN).
Также повысилась надежность при работе с большим числом сайтов — это, несомненно, пригодится для резервного копирования и репликации.
В пользу WireGuard как фактически нового стандарта для VPN высказался сам Линус Торвальдс:
«Can I just once again state my love for [WireGuard] and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.»Команда разработчиков Veeam PN соответственно переписала исходный код.
Linus Torvalds, on the Linux Kernel Mailing List
«Могу ли я еще раз выразить свою любовь и надежду на скорое включение его в ядро? Может быть, код не идеален, но, по сравнению с ужасами OpenVPN и IPSec, это произведение искусства.»
Линус Торвальдс, в почтовой рассылке Linux Kernel
Важно! При этом, как вы понимаете, апгрейд для пользователей версии 1.0 стал невозможен, требуется полная переустановка.
Улучшенная безопасность, повышенная производительность
Одной из причин перехода с OpenVPN на WireGuard стала улучшенная безопасность в WireGuard. А безопасность — один из ключевых моментов для любого решения VPN.
WireGuard задействует крипто-версионирование для предупреждения крипто-атак. Аргументация такова: при аутентификации проще работать с версиями примитивов, нежели задействовать клиент-серверное согласование типа шифра и длин ключей.
Благодаря такому подходу к шифрованию, а также эффективности кода с WireGuard удается достичь более высоких показателей производительности, чем с OpenVPN.
Это означает, что новая версия решения Veeam PN может справляться со значительно большими объемами информации — в 5-20 раз больше, чем OpenVPN, согласно результатам тестов (в зависимости от конфигурации процессора). С такой производительностью новую технологию ожидает гораздо больший спектр задач, нежели простая передача данных из удаленного офиса или из домашней лаборатории. Уже сегодня Veeam PN — это способ не только установить безопасное соединение между несколькими сайтами, но и передавать без помех сотни мегабит в секунду — а это очень пригодится для защиты и восстановления данных.
Возможность выбора протокола
Один из нюансов в работе WireGuard — использование UDP. Считается, что это может стать препятствием к применению WireGuard в защищенных сетях, в которых, по умолчанию, предпочтительнее использование TCP, чем UDP.
Чтобы преодолеть это ограничение, наши инженеры придумали вариант с инкапсуляцией: шифрованный UDP-траффик передается по TCP-туннелю. Теперь у пользователей будет возможность выбрать подходящую опцию (работать с TCP или UDP) в зависимости от настроек сетевой безопасности.
Установка и настройка совсем несложные — WireGuard можно установить на сервере Ubuntu с помощью скрипта, есть и вариант со встраиванием в апплаенс.
Примечание: OpenVPN по-прежнему используется для соединения point-to-site (от точки к сайту), поскольку клиенты OpenVPN широко распространены на разных платформах. Клиентский доступ к хабу Veeam PN осуществляется через OpenVPN, а соединение site-to-site (от сайта к сайту) — с использованием WireGuard (см. примеры выше).
И еще кое-что
Помимо перехода на WireGuard для соединений site-to-site, у Veeam PN 2.0 есть и другие новые фичи, в частности:
- Поддержка прямой DNS-переадресации, автоматическая передача настроек DNS на клиентские машины для определения FQDNs во всех подключенных сайтах.
- Улучшения в интеграции с Microsoft Azure.
- Новый отчет о ходе процедуры развертывания.
YourChief
Приведённое Вами утверждение ничем не подкреплено. Кроме этого, по информации с официального сайта ни одного стабильного релиза так и не было:
То есть авторы не пока не рассматривают его как production ready.
Мне попадалось это утверждение в статьях о Wireguard, но в самой спецификации нет вообще ничего про версию. Надо понимать, что это такая обтекаемая форма утверждения «в случае чего просто поменяем всё под корень».
Говоря о производительности самого Wireguard, следует заметить что рекордные скорости он достигает благодаря размещению модулем прямо в ядре Linux. На всех остальных платформах, где Wireguard реализован в юзерспейсе, скорость будет сопоставимая с OpenVPN и будет проигрывать решениям, которые реализованы драйвером в ядре (например, IKEv2 IPsec).
Wireguard модный, перспективный, но пока он не конкурент даже IPsec по причине неполного соответствия функционалу обычных VPN-серверов и отсутствия зрелости.
FrozenWalrus
Вообще, проводилось множество исследований криптостойкости WireGuard, как конкретной реализации, так и самого протокола. Навскидку, вот и вот. К тому же, аудит 4000 строк кода не в пример легче, чем аудит сотен тысяч.
Кроме того, WireGuard (по крайней мере kernel версия) использует реализацию крипто-примитивов и самого протокола, сгенерированных с использованием методов формальной верификации. Неплохо зная внутреннее устройство OpenVPN, я даже не могу представить, чтобы можно было полностью формально верифицировать или доказать криптостойкость протокола OpenVPN, хотя попытки были, например вот тут.
Множество, только абсолютное большинство из них уже устарело. Из тех шифров, которые удовлетворяют современным требованиям я бы назвал только AES-128/192/256-CBC. И то, CBC режим подвержен уязвимостям .
Поддержка современных режимов шифрования (e.g. AES-256-GCM) и perfect forward secrecy (e.g. ECDHE) появилась только в версии 2.4 и не поддерживается в более старых версиях, которых до сих пор полно на просторах сети. В общем и целом, OpenVPN гораздо проще настроить неправильно, с использованием небезопасной криптографии.
В качестве примера, в TLS 1.0-1.2 поддерживалось огромное количество crypto suites, но в TLS 1.3 выкинули абсолютное большинство из них, оставив (и несколько добавив) очень малую часть крипто наборов. Из-за этого (и из-за изменений в протоколе) клиенты TLS 1.2 не имеют возможности подключиться к TLS 1.3 only серверам. А в TLS 1.1 и 1.2 множество крипто наборов помечены как небезопасные или условно-безопасные. И тут уж зависит от конфигурации конкретных серверов/клиентов будут ли использоваться эти слабые крипто наборы. По мне так лучше вообще потерять возможность соединения, чем пользоваться небезопасной криптографией.
Для WireGuard тоже можно придумать реализацию PKI, благо клиенты и так аутентифицируются по публичным/приватным ключам, которые суть есть Curve25519, так что можно раздавать клиентам те же ECC SSL сертификаты. То, что поддержка PKI не зашита в протокол WireGuard по-моему только плюс. Это, конечно, может быть минусом для корпоративного сектора, но думаю и там в скором времени найдётся решение.
При этом о поддержкe WireGuard и предоставлении сервисов на его основе уже заявило большинство крупнейших VPN провайдеров. А Cloudflare, например, вообще свою реализацию WireGuard протокола на Rust написали.
Насчёт сравнения с OpenVPN я бы поспорил. Реализация протокола поверх UDP в OpenVPN довольно примитивна: обычное скользящее окно фиксированного размера (на 8 пакетов если правильно помню), с возможностью подтверждения доставки сразу нескольких пакетов. Реализация сетевого взаимодействия в WireGuard тоже далека от оптимальной, но в отличие от OpenVPN, тут есть возможность использовать все доступные CPU для шифрования и обработки пакетов. OpenVPN же в версии 2.X все данные всегда обрабатывает в однопоточном режиме. Версия 3.X, в которой добавлена поддержка многопоточности, уже более 7 лет находится в состоянии разработки, ни одного релиза так до сих пор и не было.
Тут, конечно, только время покажет, но лично я голосую за WireGuard :-)
YourChief
Да, я сам использовал в прошлом AzireVPN потому, что они начали поддерживать wireguard. Однако, вот что:
- Поддержку wireguard выкатили на данный момент только, наоборот, самые мелкие провайдеры. Они в первую очередь заинтересованы в уникальном торговом предложении, а не в реальной безопасности. Поэтому AzireVPN наряду с wireguard предлагает и SOCKS5 без шифрования, а, например, vpn.ac предлагает PPTP (с MPPE на шифре RC4) и L2TP/IPsec с PSK для аутентификации сервера, который знают все клиенты. Wireguard на слуху, вот они и подсуетились. А старые протоколы поддерживают потому что и на них есть спрос со стороны владельцев старого оборудования. То есть, это из-за спроса, а не из-за безопасности.
- Вероятнее всего, CF пилил эту реализацию для своего Cloudflare Warp, который недавно запустился. Это VPN для мобильных и wireguard туда отлично вписывается потому, что прочно держит соединение, тут лучше чем wireguard и правда не придумать. Кроме того CF ещё имеет кое-какие амбиции по борьбе с цензурой, а у wireguard обфусцированный протокол.
Так помимо блочного шифра транспортного канала, с которым проблем и так особо нет, в шифронабор входят вариации согласования ключей по Диффи-Хеллману, псевдослучайная функция и асимметричные ключи подписи, к которым обычно больше вопросов. Вот в вайргарде оно всё прибито гвоздями, в OpenVPN и других хотя бы пара рабочих вариантов есть. И по той причине, что в протоколе wireguard применяется обфускация точек эллиптической кривой, которая специфична для этой конкретной кривой, по-другому не будет, там можно весь шифронабор только разом сменить.Общего решения, сохраняющего свойства wireguard, не найдётся точно, потому что обнажение публичных ключей идёт вразрез с целями протокола Noise. Wireguard использует паттерн IK протокола Noise, и для получения гарантий, которые он предоставляет, инициатор должен знать публичный ключ ответчика заблаговременно.
В тот же OpenVPN PKI тоже не прямо жёстко зашита — можно использовать статический ключ. Кстати тогда возникает вопрос про вайргард: если мне ещё и ключи нужно так скрупулёзно распространять, зачем мне тогда DH встроенный в wireguard? Чего б тогда сразу статический ключ не назначать, раз оно без внешних костылей или ручной работы не работает? В своей презентации они такой способ, кстати, и рекомендуют, как возможный способ достижения постквантового шифрования. Но в дикой природе реализации wireguard, поддерживающие статический ключ, мне не попадались пока.
FrozenWalrus
Ох, RC4 — это они зря)) Наверное, в нынешнее время любой калькулятор сможет в режиме реального времени расшифровывать этот поточный шифр.
Кстати, в рассылке WireGuard поступали предложения изменить протокол так, чтобы DPI системам сложнее было обнаруживать и классифицировать траффик WG, но автор ни в какую не соглашается. Там же в рассылке упоминалось, что великий китайский файрволл уже умеет детектировать и блокировать траффик WG.
С блочным шифром канала, кстати, возникает довольно много проблем (BEAST, POODLE). Вернее, с правильным использованием шифра. Взять к примеру тот же GCM режим — достаточно использовать один и тот же initialization vector дважды с одним ключом шифрования, чтобы полностью скомпроментировать этот ключ. Многие реализации грешат (или грешили) тем, что использовали псевдослучайный IV, а так как в GCM режиме размер вектора всего 12 байт, то при использовании PRNG низкого качества не исключена была вероятность повторов.
А по поводу смены всего шифронабора — по сути как я и писал, даже в TLS почти тот же подход — либо обновляешься на новую несовместимую версию, либо используешь предыдущую уязвимую, надеясь, что все известные слабые шифронаборы отключены, и что при этом у сервера и клиента остался хоть один общий вариант шифро-параметров.
Можно предположить какой-нибудь вариант, например, при котором удостоверяющий центр аутентифицирует клиента и выдает ему временную пару public/private ключей для WireGuard, которые можно использовать аналогично токенам Kerberos. Конечно, тут возникает проблема в том, что удостоверяющий центр сам должен после этого передать временный публичный ключ на сервер WireGuard, а это идёт вразрез с принципами PKI. Но при этом на сервер WireGuard не попадают данные, позволяющие связать временный публичный ключ с конкретным клиентом.
Хотя бы для обеспечения perfect forward secrecy, чтобы при компроментации ключа WG, злоумышленник не смог расшифровать предыдущие сессии.
Статический ключ — имеется ввиду pre-shared key? Если да, то по крайней мере в kernel версии они поддерживается и в Veeam PN используется для дополнительной безопасности.
YourChief
В отношении DPI, наверное, самая выгодная стратегия — быть неотличимым от HTTPS и прочих виды «легетимного» шифрованного трафика. Тем более что в самом TLS уже есть всё неоходимое для шифрования.
FrozenWalrus
Я видел информацию об этом в рассылке WireGuard, постараюсь найти.