Оффлайн
- Регистрация
- 23.09.18
- Сообщения
- 12.347
- Реакции
- 176
- Репутация
- 0
Нет худа без добра!
В очередной раз народная мудрость подтверждается, но только в этот раз с помощью осточертевшего коронавируса. Всех перевели на удалёнку, открыто много подписочного контента и, как следствие, в телекоме произошёл взрывной рост трафика. По разным оценкам, трафик в пользовательских сегментах уже вырос процентов на 80% и не думает останавливаться. Трафик попёр настолько сильно, что в нескольких странах Netflix, Youtube и прочие стриминговые сервисы сначала просили ограничить, а теперь им фактически запрещают передачу контента в HD качестве. Ибо пользователи настолько активно взялись за работу из дома, что места для развлечений в каналах у операторов просто не осталось.
А вот кто действительно сейчас не успевает подставлять мешки под поток хлынувших денег, так это провайдеры VPN-сервисов и всех, кто связан с их обслуживанием. Благо у одних своего VPN не было и проще купить готовый сервис, у других он был просто не рассчитан на такой поток пользователей и скончался под нагрузкой в первый же день. Словом, VPN — это сейчас самое популярное слово в телеком-мире. Вероятно, даже популярнее этой проклятой чумы.
И вот тут стоит задать себе вопрос — а в чём же сложность взять и организовать удобный VPN-сервис, а затем просто поддерживать его? Технология придумана далеко не вчера, все варианты давно известны, так почему же вокруг неё столько разговоров?
Но дабы не писать миллион первую статью про тонкости настройки OpenVPN, IPSec и прочих, давайте подойдём с другой стороны — а бывает так, что VPN делается быстро, удобно и бесплатно? Вот чтобы действительно десяток кликов — и работает как часы. И site-to-site, чтобы офисы связать, и site-to-point, чтобы удалёнщикам было быстро и удобно.
Спойлер — бывает.
Пруфы и рассуждения — под катом.
Отрицание
Итак, все работодатели, отправившие людей домой, крепко задумались о двух вещах: как обеспечить доступ сотрудников к данным, необходимым им для работы, и как бы эти данные обезопасить. Ответ на оба вопроса находится в плоскости используемого VPN-решения, а значит, пора рассмотреть, какие у нас есть варианты по его организации.
Вариант банальный: сжимаем деньги в кулачок и покупаем готовое решение. Возможно, даже с поддержкой. Такие решения поставляются в виде готовых сервисов. Вы у себя в сети разворачиваете приложение, подключаете его к сервис-провайдеру, дальше случается магия роутинга, и всё, что вам остаётся делать — это раздать сотрудникам ссылку на приложение и коротенькую инструкцию для подключения. Вариант очень хороший, но а) обычно стоит больших денег б) от ваших потребностей ничего не зависит, пользуйся тем, что дают.
Вариант дешевле, но не такой простой: самостоятельно разворачиваем выбранное on-premise решение. Ещё недавно практически любой сисадмин показал бы вам пальцем на OpenVPN. Он действительно хорош, он может просто стабильно работать но с ним была проблема — для его настройки новичку (да и не только новичку, давайте честно) приходилось серьёзно углубиться в документацию и россыпь конфигов, чтобы потом просто плюнуть и реализовать одно из решений, предлагаемых в сети. Затем следовало написание сложносочинённой инструкции для пользователя, выдача ему файла с ключами и увлекательная беседа по телефону, когда пользователь даже с инструкцией не понимает, куда и что вводить в OpenVPN клиенте. А на серверной стороне была вечная проблема с довольно низкой производительностью.
Но затем в мир пришёл WireGuard, и ситуация здорово изменилась в положительную сторону. Написанный с нуля протокол легко уделал ветерана по производительности и возможностям масштабирования, за что уже включен в ядро 5.6. А сам господин Торвальдс непрозрачно намекает, что WireGuard вскоре станет новым стандартом. Правда, работает он только по UDP, но это даже и не особо большой минус. А вот из действительных минусов — это отсутствие механизмов для обеспечения удобного роутинга. То есть для домашнего использования или решения проблем уровня “соединить два сайта с двумя подсетями” он подходит, но когда требуется сделать уже нечто масштабное, там могут быть сложности. Да и всё того же централизованного управления нет, а хочется. Но создатели прямо говорят, что заниматься обвязкой вокруг самого протокола им не интересною
Принятие
В 2017 году в качестве одного из компонентов Veeam Backup & Replication, а именно Veeam Restore to Microsoft Azure, был написан побочный продукт для автоматической организации связи между площадками и максимальной утилизации возможностей канала связи. Впоследствии оно получит своё уникальное имя — Veeam PN (сокращение от Powered Network).
Чтобы быть уверенным, что восстановление машин прошло успешно и ими можно пользоваться так, будто они находятся рядом с остальными, необходимо организовать до них VPN. То есть зайти на машину, залить сертификаты, конфиги, убедиться, что клиент не может достучаться до сервера, хлопнуть себя по лбу, пойти перенастроить сервер, и так далее. Словом, множество увлекательных, но крайне просто автоматизируемых вещей, заниматься которыми нет никакого желания. Особенно, если всё тоже самое можно сделать нажиманием нескольких кнопок в Web GUI.
И как это часто бывает с приложениями, легко и красиво решающими насущные проблемы, инструмент пришёлся многим по душе и вскоре стал использоваться не только в рамках продукта, и не только для изначальных целей. Как оказалось, чисто вимовская фишка про it just works в виде Next, Next, Finish помогала людям организовывать не просто связь между домом и офисом, но и связывать сети на удалённых площадках с облаками, не забывая подключить локальную машину.
Словом, стало понятно, что надо развивать продукт дальше. Но тут образовалась проблема — используя OpenVPN под капотом в первых версиях, наше решение не могло выдавать необходимый уровень производительности, независимо от количества выделяемых CPU и остальных ресурсов. Пришла пора кардинальных изменений.
Veeam PN v2 с WireGuard
Сейчас, когда уже отгремели баталии между последователями OpenVPN и свидетелями WireGuard, можно достаточно уверенно утверждать — за новым протоколом будущее. Он работает прямо в ядре ОС, повышает уровень безопасности благодаря расширенным возможностям криптографии и намного более производителен. Банально, он занимает 4 000 строчек кода вместо 60 000 у OpenVPN.
Поэтому было принято решение о внедрении в продукт новичка и использование его возможностей для организации VPN-подключений между площадками. По нашим тестам получилось, что в зависимости от конфигурации лабораторных машин можно получить прирост скорости работы соединения от 5 до 20 раз. Это позволяет использовать его уже не просто как резервный канал связи до удалённого офиса или домашней лабы, а в виде полноценного канала связи нескольких площадок, со скоростями в сотни мегабит. Для наших целей (передача больших объёмов данных при бекапах и послеаварийном восстановлении) решение получилось просто фантастическим.
Но есть у WireGuard нюанс. Не проблема, а именно нюанс: он работает по UDP. Для связи point-to-site это совершенно не критично, а вот для связи между площадками предпочтительнее использовать TCP. Чтобы решить эту проблему, наши разработчики добавили инкапсуляцию UDP трафика WireGuard в TCP. Звучит громоздко, но тесты показывают обратное. Да и мы оставили возможность выбора используемого транспорта.
А вот для связи point-to-site мы пока используем OpenVPN, но только из-за гораздо большей его распространённости на разных платформах. Как только для WireGuard появятся стабильные клиентские приложения под все платформы, мы планируем дальнейшее его внедрение.
Практическое занятие
В основе — неважно, point-to-site или site-to-site — соединения будет лежать Veeam PN Server, он же network hub. Это приложение — оркестратор, замыкающее на себя все соединения и обеспечивающее роутинг, шифрование, работу с пользователями, мониторинг и так далее. Представляет из себя небольшой OVA образ (буквально 300 Mb) Linux-машины, который можно развернуть на любой площадке. А раз исторические корни находятся в Azure, то образ есть даже прямо в Azure Marketplace. И, конечно же, не забыт AWS Marketplace. А для самых скучающих есть вариант установки прямо на вашу
Итак, скачиваем OVA файл и разворачиваем машину самым обычным образом. После деплоя открываем в браузере IP новой машины. Если проделать это достаточно быстро, то можно застать стадию инициализации, о чём будет сообщено в явном виде.
Затем высветится форма авторизации, где надо ввести
User: root
Password: VeeamPN
После этого вам будет предложено сразу сменить дефолтный пароль, ибо грешновато так не делать.
И запустится мастер первичной настройки. По верной традиции всё настроенное на этом шаге можно безболезненно изменить в дальнейшем.
Выбираем Network Hub и переходим к шагу, где надо указать имя самоподписного сертификата и уровень шифрования. По умолчанию установлено 2048. и если вас это устраивает, то запустится процесс генерации.
Затем надо указать IP или DNS имя, по которому будет доступен наш сервер, и включить необходимые варианты доступа, выбрав порты и протоколы. И на этом первичная настройка заканчивается.
Перед нами открывается дашборд со статистикой, но пока он ожидаемо пуст и скучен, поэтому давайте добавим point-to-site клиента. Идём в Clients > Add и выбираем Standalone computer.
Важно: по умолчанию, у клиента не будет доступа никуда дальше самого аплаенса. Чтобы включить роутинг в локальные сети, надо добавить клиентов с ролью Hub для всех сетей, куда необходим доступ. Фактически, это прости вирутальные интерфейсы, для которых будет настроен роутинг. Аплаенсы в AWS и Azure делают это автоматически.
Задаём клиенту понятное для нас имя, которое в дальнейшем не будет вызывать вопросов, решаем, выступать вашему хабу в качестве default gateway или нет, Next > Finish и на этом всё!
Здесь же вам будет показаны ссылка на последнюю версию OpenVPN клиента и ссылка для скачивания готового конфига для конкретно этого клиента.
Потом на клиенте запускаем установщик OpenVPN, импортируем скачанный конфиг и всё! Оно работает! Просто и понятно.
Не надо никаких сертификатов, ползанья по вкладкам с настройками и тщательного прожимания тридцати трёх галочек. Оно просто работает.
Возвращаемся на дашборд, видим наш коннект и наслаждаемся жизнью.
Чтобы жизнь мёдом не казалась и для большей честности сразу предупреждаю: ваш фаервол за вас мы настроить не сможем, как и трансляцию IP адресов. Для IP translation есть отдельная вкладка, где надо указать все необходимые переходы.
И тут ещё один важный (и возможно неприятный нюанс) — если в дальнейшем изменить настройки вашего VPN хаба (IP, порты или протоколы), то все клиентские конфиги моментально протухнут, и надо будет раздать их заново. Так что планирование — наше всё!
Что ещё можно сделать интересного?
На вкладке Settings > Alerts есть преднастроенные алерты на самые важные случаи в жизни любого VPN: клиент присоединился, отсоединился, большая нагрузка на CPU и всё сломалось. На каждое событие есть два варианта реакций: отправить письмо или запустить некий скрипт. Если этого мало, здесь же можно сделать свои кастомные варианты срабатывания тригеров.
Про site-to-site замолвите слово
А что со случаем, если нам надо организовать связь между офисами? Или офисом и облаком?
Здесь появляется новая сущность — site gateway. Это такая же небольшая машина, которая установит соединение с вашим network hub и будет выступать гейтвеем для машин внутри сети.
В случае нескольких сетей (или филиалов) вы фактически построите сеть с топологией типа звезда, где весь трафик всегда будет роутиться через network hub.
А что с DNS?
Начиная с версии 2.0, Veeam PN поддерживает перенаправление DNS запросов. Это значит, что клиенты смогут резолвить все FQDN во всех сетях. Для этого на хабе хранятся все суффиксы сетей, участвующих в VPN, и через это мы можем резолвить имена машин.
Под капотом это dnsmasq, работающий на 53 порту. А конфиг, куда попадают IP используемых серверов, можно посмотреть по адресу /etc/veeampn/dns/listen_addrs.conf
Важно: при использовании site-to-site необходимо на клиентских маших обязательно включить IP хаба в список DNS резолверов. Или настроить форвардинг на локальном DNS сервере. Автоматически это сделать мы, конечно же, не можем.
Само собой, если в такой функции нет надобности, она отключается одним кликом в WebUI.
На этом всё!
Пользуйтесь с удовольствием! Решение абсолютно бесплатное.
Скачать можно
Вся документация лежит
Обсудить, покритиковать или высказать свои предложения по улучшению, можно напрямую с ответственным за продукт, на нашем
В очередной раз народная мудрость подтверждается, но только в этот раз с помощью осточертевшего коронавируса. Всех перевели на удалёнку, открыто много подписочного контента и, как следствие, в телекоме произошёл взрывной рост трафика. По разным оценкам, трафик в пользовательских сегментах уже вырос процентов на 80% и не думает останавливаться. Трафик попёр настолько сильно, что в нескольких странах Netflix, Youtube и прочие стриминговые сервисы сначала просили ограничить, а теперь им фактически запрещают передачу контента в HD качестве. Ибо пользователи настолько активно взялись за работу из дома, что места для развлечений в каналах у операторов просто не осталось.
А вот кто действительно сейчас не успевает подставлять мешки под поток хлынувших денег, так это провайдеры VPN-сервисов и всех, кто связан с их обслуживанием. Благо у одних своего VPN не было и проще купить готовый сервис, у других он был просто не рассчитан на такой поток пользователей и скончался под нагрузкой в первый же день. Словом, VPN — это сейчас самое популярное слово в телеком-мире. Вероятно, даже популярнее этой проклятой чумы.
И вот тут стоит задать себе вопрос — а в чём же сложность взять и организовать удобный VPN-сервис, а затем просто поддерживать его? Технология придумана далеко не вчера, все варианты давно известны, так почему же вокруг неё столько разговоров?
Но дабы не писать миллион первую статью про тонкости настройки OpenVPN, IPSec и прочих, давайте подойдём с другой стороны — а бывает так, что VPN делается быстро, удобно и бесплатно? Вот чтобы действительно десяток кликов — и работает как часы. И site-to-site, чтобы офисы связать, и site-to-point, чтобы удалёнщикам было быстро и удобно.
Спойлер — бывает.
Пруфы и рассуждения — под катом.
Отрицание
Итак, все работодатели, отправившие людей домой, крепко задумались о двух вещах: как обеспечить доступ сотрудников к данным, необходимым им для работы, и как бы эти данные обезопасить. Ответ на оба вопроса находится в плоскости используемого VPN-решения, а значит, пора рассмотреть, какие у нас есть варианты по его организации.
Вариант банальный: сжимаем деньги в кулачок и покупаем готовое решение. Возможно, даже с поддержкой. Такие решения поставляются в виде готовых сервисов. Вы у себя в сети разворачиваете приложение, подключаете его к сервис-провайдеру, дальше случается магия роутинга, и всё, что вам остаётся делать — это раздать сотрудникам ссылку на приложение и коротенькую инструкцию для подключения. Вариант очень хороший, но а) обычно стоит больших денег б) от ваших потребностей ничего не зависит, пользуйся тем, что дают.
Вариант дешевле, но не такой простой: самостоятельно разворачиваем выбранное on-premise решение. Ещё недавно практически любой сисадмин показал бы вам пальцем на OpenVPN. Он действительно хорош, он может просто стабильно работать но с ним была проблема — для его настройки новичку (да и не только новичку, давайте честно) приходилось серьёзно углубиться в документацию и россыпь конфигов, чтобы потом просто плюнуть и реализовать одно из решений, предлагаемых в сети. Затем следовало написание сложносочинённой инструкции для пользователя, выдача ему файла с ключами и увлекательная беседа по телефону, когда пользователь даже с инструкцией не понимает, куда и что вводить в OpenVPN клиенте. А на серверной стороне была вечная проблема с довольно низкой производительностью.
Но затем в мир пришёл WireGuard, и ситуация здорово изменилась в положительную сторону. Написанный с нуля протокол легко уделал ветерана по производительности и возможностям масштабирования, за что уже включен в ядро 5.6. А сам господин Торвальдс непрозрачно намекает, что WireGuard вскоре станет новым стандартом. Правда, работает он только по UDP, но это даже и не особо большой минус. А вот из действительных минусов — это отсутствие механизмов для обеспечения удобного роутинга. То есть для домашнего использования или решения проблем уровня “соединить два сайта с двумя подсетями” он подходит, но когда требуется сделать уже нечто масштабное, там могут быть сложности. Да и всё того же централизованного управления нет, а хочется. Но создатели прямо говорят, что заниматься обвязкой вокруг самого протокола им не интересною
Принятие
В 2017 году в качестве одного из компонентов Veeam Backup & Replication, а именно Veeam Restore to Microsoft Azure, был написан побочный продукт для автоматической организации связи между площадками и максимальной утилизации возможностей канала связи. Впоследствии оно получит своё уникальное имя — Veeam PN (сокращение от Powered Network).
Чтобы быть уверенным, что восстановление машин прошло успешно и ими можно пользоваться так, будто они находятся рядом с остальными, необходимо организовать до них VPN. То есть зайти на машину, залить сертификаты, конфиги, убедиться, что клиент не может достучаться до сервера, хлопнуть себя по лбу, пойти перенастроить сервер, и так далее. Словом, множество увлекательных, но крайне просто автоматизируемых вещей, заниматься которыми нет никакого желания. Особенно, если всё тоже самое можно сделать нажиманием нескольких кнопок в Web GUI.
И как это часто бывает с приложениями, легко и красиво решающими насущные проблемы, инструмент пришёлся многим по душе и вскоре стал использоваться не только в рамках продукта, и не только для изначальных целей. Как оказалось, чисто вимовская фишка про it just works в виде Next, Next, Finish помогала людям организовывать не просто связь между домом и офисом, но и связывать сети на удалённых площадках с облаками, не забывая подключить локальную машину.
Словом, стало понятно, что надо развивать продукт дальше. Но тут образовалась проблема — используя OpenVPN под капотом в первых версиях, наше решение не могло выдавать необходимый уровень производительности, независимо от количества выделяемых CPU и остальных ресурсов. Пришла пора кардинальных изменений.
Veeam PN v2 с WireGuard
Сейчас, когда уже отгремели баталии между последователями OpenVPN и свидетелями WireGuard, можно достаточно уверенно утверждать — за новым протоколом будущее. Он работает прямо в ядре ОС, повышает уровень безопасности благодаря расширенным возможностям криптографии и намного более производителен. Банально, он занимает 4 000 строчек кода вместо 60 000 у OpenVPN.
Поэтому было принято решение о внедрении в продукт новичка и использование его возможностей для организации VPN-подключений между площадками. По нашим тестам получилось, что в зависимости от конфигурации лабораторных машин можно получить прирост скорости работы соединения от 5 до 20 раз. Это позволяет использовать его уже не просто как резервный канал связи до удалённого офиса или домашней лабы, а в виде полноценного канала связи нескольких площадок, со скоростями в сотни мегабит. Для наших целей (передача больших объёмов данных при бекапах и послеаварийном восстановлении) решение получилось просто фантастическим.
Но есть у WireGuard нюанс. Не проблема, а именно нюанс: он работает по UDP. Для связи point-to-site это совершенно не критично, а вот для связи между площадками предпочтительнее использовать TCP. Чтобы решить эту проблему, наши разработчики добавили инкапсуляцию UDP трафика WireGuard в TCP. Звучит громоздко, но тесты показывают обратное. Да и мы оставили возможность выбора используемого транспорта.
А вот для связи point-to-site мы пока используем OpenVPN, но только из-за гораздо большей его распространённости на разных платформах. Как только для WireGuard появятся стабильные клиентские приложения под все платформы, мы планируем дальнейшее его внедрение.
Практическое занятие
В основе — неважно, point-to-site или site-to-site — соединения будет лежать Veeam PN Server, он же network hub. Это приложение — оркестратор, замыкающее на себя все соединения и обеспечивающее роутинг, шифрование, работу с пользователями, мониторинг и так далее. Представляет из себя небольшой OVA образ (буквально 300 Mb) Linux-машины, который можно развернуть на любой площадке. А раз исторические корни находятся в Azure, то образ есть даже прямо в Azure Marketplace. И, конечно же, не забыт AWS Marketplace. А для самых скучающих есть вариант установки прямо на вашу
You must be registered for see links
руками или с помощью скрипта. Там же, по ссылке, есть и подробная документация на все случаи жизни.Итак, скачиваем OVA файл и разворачиваем машину самым обычным образом. После деплоя открываем в браузере IP новой машины. Если проделать это достаточно быстро, то можно застать стадию инициализации, о чём будет сообщено в явном виде.
Затем высветится форма авторизации, где надо ввести
User: root
Password: VeeamPN
После этого вам будет предложено сразу сменить дефолтный пароль, ибо грешновато так не делать.
И запустится мастер первичной настройки. По верной традиции всё настроенное на этом шаге можно безболезненно изменить в дальнейшем.
Выбираем Network Hub и переходим к шагу, где надо указать имя самоподписного сертификата и уровень шифрования. По умолчанию установлено 2048. и если вас это устраивает, то запустится процесс генерации.
Затем надо указать IP или DNS имя, по которому будет доступен наш сервер, и включить необходимые варианты доступа, выбрав порты и протоколы. И на этом первичная настройка заканчивается.
Перед нами открывается дашборд со статистикой, но пока он ожидаемо пуст и скучен, поэтому давайте добавим point-to-site клиента. Идём в Clients > Add и выбираем Standalone computer.
Важно: по умолчанию, у клиента не будет доступа никуда дальше самого аплаенса. Чтобы включить роутинг в локальные сети, надо добавить клиентов с ролью Hub для всех сетей, куда необходим доступ. Фактически, это прости вирутальные интерфейсы, для которых будет настроен роутинг. Аплаенсы в AWS и Azure делают это автоматически.
Задаём клиенту понятное для нас имя, которое в дальнейшем не будет вызывать вопросов, решаем, выступать вашему хабу в качестве default gateway или нет, Next > Finish и на этом всё!
Здесь же вам будет показаны ссылка на последнюю версию OpenVPN клиента и ссылка для скачивания готового конфига для конкретно этого клиента.
Потом на клиенте запускаем установщик OpenVPN, импортируем скачанный конфиг и всё! Оно работает! Просто и понятно.
Не надо никаких сертификатов, ползанья по вкладкам с настройками и тщательного прожимания тридцати трёх галочек. Оно просто работает.
Возвращаемся на дашборд, видим наш коннект и наслаждаемся жизнью.
Чтобы жизнь мёдом не казалась и для большей честности сразу предупреждаю: ваш фаервол за вас мы настроить не сможем, как и трансляцию IP адресов. Для IP translation есть отдельная вкладка, где надо указать все необходимые переходы.
И тут ещё один важный (и возможно неприятный нюанс) — если в дальнейшем изменить настройки вашего VPN хаба (IP, порты или протоколы), то все клиентские конфиги моментально протухнут, и надо будет раздать их заново. Так что планирование — наше всё!
Что ещё можно сделать интересного?
На вкладке Settings > Alerts есть преднастроенные алерты на самые важные случаи в жизни любого VPN: клиент присоединился, отсоединился, большая нагрузка на CPU и всё сломалось. На каждое событие есть два варианта реакций: отправить письмо или запустить некий скрипт. Если этого мало, здесь же можно сделать свои кастомные варианты срабатывания тригеров.
Про site-to-site замолвите слово
А что со случаем, если нам надо организовать связь между офисами? Или офисом и облаком?
Здесь появляется новая сущность — site gateway. Это такая же небольшая машина, которая установит соединение с вашим network hub и будет выступать гейтвеем для машин внутри сети.
В случае нескольких сетей (или филиалов) вы фактически построите сеть с топологией типа звезда, где весь трафик всегда будет роутиться через network hub.
А что с DNS?
Начиная с версии 2.0, Veeam PN поддерживает перенаправление DNS запросов. Это значит, что клиенты смогут резолвить все FQDN во всех сетях. Для этого на хабе хранятся все суффиксы сетей, участвующих в VPN, и через это мы можем резолвить имена машин.
Под капотом это dnsmasq, работающий на 53 порту. А конфиг, куда попадают IP используемых серверов, можно посмотреть по адресу /etc/veeampn/dns/listen_addrs.conf
Важно: при использовании site-to-site необходимо на клиентских маших обязательно включить IP хаба в список DNS резолверов. Или настроить форвардинг на локальном DNS сервере. Автоматически это сделать мы, конечно же, не можем.
Само собой, если в такой функции нет надобности, она отключается одним кликом в WebUI.
На этом всё!
Пользуйтесь с удовольствием! Решение абсолютно бесплатное.
Скачать можно
You must be registered for see links
.Вся документация лежит
You must be registered for see links
.Обсудить, покритиковать или высказать свои предложения по улучшению, можно напрямую с ответственным за продукт, на нашем
You must be registered for see links
.