VPN с человеческим лицом существует?

    Нет худа без добра! В очередной раз народная мудрость подтверждается, но только в этот раз с помощью осточертевшего коронавируса. Всех перевели на удалёнку, открыто много подписочного контента и, как следствие, в телекоме произошёл взрывной рост трафика. По разным оценкам, трафик в пользовательских сегментах уже вырос процентов на 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. А для самых скучающих есть вариант установки прямо на вашу Ubuntu руками или с помощью скрипта. Там же, по ссылке, есть и подробная документация на все случаи жизни.


    Итак, скачиваем 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.


    На этом всё!


    Пользуйтесь с удовольствием! Решение абсолютно бесплатное.


    → Скачать можно здесь.
    → Вся документация лежит вот тут.


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

    Veeam Software
    Продукты для резервного копирования информации

    Comments 23

      +3
      Что-то вы начали «за здравие, а закончили за упокой» — своими словами: «OpenVPN — это сложно и потери производительности, а новый WireGuard — это новое будущее»! И всю статью описывали особенности настройки OpenVPN через Ваш продукт, и далее про WireGuard ни слово — так и где «Veeam PN v2 с WireGuard» в разделе?
        +2
        WireGuard используется в site-to-site, а OpenVPN в point-to-site. Настраиваются они абсолютно одинаково через Next>Next>Finish и совершенно прозрачно для пользователя.
        Как и сказано в статье: клиенты под разные платформы у WireGuard сейчас довольно сырые, поэтому OpenVPN был оставлен для подключения конечных устройств. Когда появятся стабильные клиенты для windows и mac, а не версии 0.1.0 , тогда можно будет и раздавать его пользователям, не опасаясь внезапных сюрпризов.
          0
          Т.е. вы уже считаете, что в «продакшен» можно внедрять, в варианте соединения офисов-филиалов или площадок, и можно заменить IPSec (весьма не тривиальный в настройке), на WireGuard через ваш продукт?
            +1
            Да, вполне. В ядро 5.6 он уже включен, в RHEL тоже имеется. Наш продукт это просто удобный Web GUI, избавляющий вас от настроечной рутины.

            Другой вопрос, что если у вас уже есть работающий IPSec (или что-то другое) и он вас полностью устраивает, то необходимости всё сносить я не вижу.
        +2
        Справедливости ради, OpenVPN достаточно легко настраивается при использовании продуктов типа pfSense или OpnSense. Прямо из веб-морды формируется пачка конфигов (включая пользовательские сертификаты), и инструкция пользователю сокращается до 4-х строчек:
        1) Скачать программу-клиент тут;
        2) Установить;
        3) конфиги из почты переложить в такой-то каталог;
        4) Кликнуть на иконку и нажать «Подключиться»;

        Банально, он занимает 4 000 строчек кода вместо 60 000 у OpenVPN.


        Ну так ещё бы — если выкинуть кучу функционала — хитрые настройки роутинга и т. п. — то разумеется, количество строк кода существенно снизится :-)
          0
          Трудно не согласиться, что OpenVPN используется во многих решениях и не мы первые изобрели к нему адекватный gui. Сейчас каждый второй домашний роутер содержит его в себе и позволяет сделать всё тоже самое.

          Как я упоминул в статье, изначально мы решали свою проблему, а в процессе оказалось, что решение получилось удобное и полезное для многих, поэтому решили его вынести в отдельный бесплатный продукт. Вот и вся история успеха =)
          0
          а вот для связи между площадками предпочтительнее использовать TCP. Чтобы решить эту проблему, наши разработчики добавили инкапсуляцию UDP трафика WireGuard в TCP.


          Хммм
            +3
            Использую WireGuard для связи нескольких домашних сетей, сервера за границей (сами-знаете-для-чего, заворачиваются только нужные маршруты через список доменов, cron, скрипт и ipset), рабочего компьютера и сетей (~20 маршрутов), при этом используется одна сеть /24, но есть маршруты между узлами напрямую (/32, для ускорения, т. к. они в сети одного оператора). Всё работает как часы, причём, в домашних сетя всё «крутится» на роутерах с OpenWRT.
            До этого был OpenVPN и IPSec (остался и сейчас, но не использую). WireGuard нравится больше.
              0
              Добрый день,

              Подскажите, можно ли на уровне веб-интефейса Hub управлять маршрутами Standalone Computers (например одним клиентам разрешать доступ в одни подсети, другим в другие) или же любой Standalone Computer может получить доступ ко всем маршрутам доступным самому Hub?
                0
                Нет, гранулярности нет. Подразумевается, что если все клиенты в рамках одной приватной сети, то они равноправны. Если хочется делать разную топологию для разный машин или сайтов, то надо поднимать второй канал.
                0
                Никогда не понимал применение TCP в тоннелях. По этому данная фраза у меня вызывает огромные сомнения в сетевых компетенция ее писавшего( особенно в разрезе VPN Site-To-Site ):
                «а вот для связи между площадками предпочтительнее использовать TCP. Чтобы решить эту проблему, наши разработчики добавили инкапсуляцию UDP трафика WireGuard в TCP.»

                Может кто-нибудь привести кейс когда использование TCP для построения туннеля оправдано? Ну конечно кроме случая прямой блокировки UDP трафика.
                  –1
                  Ну если вам не важна целостность передачи данных, UDP — это Ваш вариант.
                    0

                    Мы сейчас говорим от vpn туннеле. Каким образов udp транспорт для инкапсулированного трафика туннеля влияет на целостность передачи данных?
                    Я бы даже сказал, каким образом он негативно влияет на "целостность", что бы это не значило, передачи данных.
                    Почему по udp туннелю "целостность" передачи будет лучше я понимаю, а вот придумать хоть один случай когда станет хуже чем в tcp туннеле не могу.
                    Приведет пример?

                      0
                      Во-первых, хочу сказать спасибо, что усомнились в компетенциях целой команды. Это очень мило. А если вы когда-то что-то не понимали, это не значит, что это что-то лишено смысла.
                      А во-вторых, ну зачем же вы так сразу с козырей-то? Неужели мало на эту тему холиворов было?
                      Да, UDP в общем случае будет быстрее, чем TCP. Но это пока пакетики в канале не теряются.
                      Зато TCP проще фаерволы проходит. Особенно когда на пути сразу несколько CONNECT/SOCKS проксей. Если несколько NAT.
                      И, вероятно, вы не поверите, но в OpenVPN используется сразу два протокола. Если установить связь с сервером по UDP не удаётся, в дело вступает TCP.
                        0
                        «Ну конечно кроме случая прямой блокировки UDP трафика.»

                        Это я сразу уточнил, фаерволы и прокси как раз покрываются этим пунктом( хотя не очень понятно как прокси связанны с VPN, они на разных сетевых уровнях работают ).

                        Квалифицированная команда написала: «а вот для связи между площадками предпочтительнее использовать TCP.». Думается мне, что всякие прокси,nat, фаерволы это очень сильно мимо Site-To-Site VPN.

                        «Да, UDP в общем случае будет быстрее, чем TCP. Но это пока пакетики в канале не теряются.»

                        Вы можете описать кейс когда при потери инкапсулированных пакетов( туннельных пакетов ) TCP будет быстрее чем UDP или обеспечит более высокое «качество» передачи? Мое понимание TCP и UDP говорит, что в случае потери пакетов TCP туннель только усугубляет ситуацию. Возможно я действительно не правильно понимаю работу эти протоколов на концах туннеля, тогда будут благодарен за разъяснения.
                          +1
                          что в случае потери пакетов TCP туннель только усугубляет ситуацию

                          Не так уж и давно на хабре была статья Дмитрия Завалишина, который, исходя как раз из таких соображений, написал UDP-версию протокола MQTT, чтобы дешевые сенсоры в домашней сети могли таки доставить свои показания до подписчиков, если в этот момент по сети стримится что-нибудь тяжелое и она забивается. Так по его практическим наблюдениям, TCP ложился от ретрансмитов гораздо раньше самых смелых предположений на этот счет.

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

                          В чем, действительно, великий смысл тройной инкапсуляции TCP -> UDP -> TCP, и как это помогает при плохом качестве канала, мне тоже было бы интересно узнать. Предположу, что «внешний» TCP сможет гораздо надежнее доставлять ретрансмиты от «внутренних» TCP. :)
                  0
                  А что таки с динамической маршрутизацией?
                    0
                    Рекомендую ознакомиться с Tinc, даже на хабре был пост habr.com/ru/post/468213
                    Автоматическая, защищенная, распределенная, с транзистивными связями (т.е. пересылкой сообщений, когда нет прямого доступа между абонентами), без единой точки отказа, равноправная, проверенная временем, с низким потреблением ресурсов, full-mesh VPN сеть c возможностью «пробивки» NAT
                      0
                      Tinc — это site-to-site, Wireguard — для site-to-point
                      OpenVPN — на свалку.
                      –2
                      Ещё недавно практически любой сисадмин показал бы вам пальцем на OpenVPN. Он действительно хорош, он может просто стабильно работать но с ним была проблема — для его настройки новичку (да и не только новичку, давайте честно) приходилось серьёзно углубиться в документацию и россыпь конфигов, чтобы потом просто плюнуть и реализовать одно из решений, предлагаемых в сети.

                      Это для человека сложно.
                      Представляет из себя небольшой OVA образ (буквально 300 Mb) Linux-машины, который можно развернуть на любой площадке.

                      А это получается легко.
                      Меня гложет вопрос — откуда у небольшой фирмы возмется гипервизор, и именно в продакшене. И как гость окажется белым адресом снаружи? Только ведь пробросом порта. И это все будет много лучше чем банальное поднятие PPtP на роутере? Да, это менее безопасно чем AES на OpenVPN и иже сним на любом современном роутере. Но в чем опасность? Все кричат про удаленную работу. А как делается эта работа? В большинстве случаев это удаленный рабочий стол — это уже шифрование. Что осталось? Внутренние сайты, голос. Что там можно секретного слить? И кто сможет перехватить трафик кроме провайдера?
                      И вот хотелось бы увидеть хоть что-то про производительность OpenVPN. Где там просадка, на каких скоростях и камнях при числености сотрудников до 100?
                      Когда мои все гуртом пошли на удаленку сомнения у меня были, что мой OpenVPN не потянет 70 человек на RDP, даже запасной корпус обул. Но G4400T @ 2.90GHz не нагружается более чем на 8% при средней загрузке канала 3.3Мб/сек
                        0
                        На Raspbian хаб поднять можно? Что читать?
                          0
                          Из чего-то похожего — zerotier (пока на Openvpn). Тоже в один клик. Можно пользовать их облако (> 100 клиентов — фри) или развернуть у себя (на хабре есть статьи по развертыванию). Удобно объединять сети с «серыми» внешними адресами, пользуя их облако.
                            0
                            Интересный продукт. Можно ли каким-то образом создать подключение point-to-site через wireguard, например, не используя штатный интерфейс? С openvpn связываться не хочется совсем.

                            Only users with full accounts can post comments. Log in, please.