Comments 56
Зачем клиентам NAT?
Хмм. Про грабли:
Управление CA - хотя и неприятно, но можно сделать на вменяемом уровне. То же создание CRL и подсовывание его серверу вполне себе автоматизируется на уровне крона. Обновление сертификатов - удобство vs безопасность, либо у тебя потерянные SSH-ключи на wg, либо забытые сертификаты на easyrsa, что технически одно и то же. Но если серт рано или поздно истечёт, то ключ - нет.
Userspace vs kernel space - грабли валидные, может наткнёмся со временем, но оверхэд там для нас не критичен настолько, чтобы решало. (Вот будь у нас 40Гбит/с снаружи, могло бы влиять по идее)
Спорные грабли. Да, wireguard меньше в виде кода, но статические (и динамические) анализаторы решают проблему аудита в поисках багов довольно эффективно. Ну и никто не застрахован от бага в либах, который можно проэксплойтить даже через идеальный код использующего приложения.
Насколько у вас сложные правила для OpenVPN, что вам надо поддерживать кастомные скрипты OpenVPN на стороне клиентов? А также, насколько часто у вас меняется конфигурация локальной сети "за" сервером OpenVPN, что надо лазать в конфиг и править там push route или ещё какие-то параметры? Один раз заточил, и оно "просто" работает. Про частые проблемы:
"Не могу зайти в VPN" - ну, штатная ситуация, можно лечить скриптами автоматического перевыпуска сертификатов, условно раз в месяц, и превентивно рассылать новые конфиги. По сравнению со статическими SSH-ключами Wireguard - удобство vs безопасность, плюс защита от забывчивости в случае увольнения кого-то, если сразу не сделали отзыв. По мне, так или иначе доступ к VPN админить надо, ваше решение не хуже многих.
OpenVPN прекрасно умеет работать по UDP - что мешает/мешало перенастроить сервер (поднять второй инстанс, начать перевозить клиентов по инструкции, ещё как) на использование UDP в качестве транспортного протокола? Проблема разрыва соединений и переподключения в мобильном роуминге решается параметром auth-gen-token (время в секундах) в конфиге сервера или CCD клиента, если нельзя на весь сервер включить.
А что это у вас кто попало лазает в easyrsa кривыми руками? Он, кстати, по логике должен жить отдельно от OpenVPN, в идеале на нормально выключенной ВМ, и бэкапаться регулярно, как центр доверия системы VPN. И при нормальной безопасности разрешение на вход по VPN должно выдаваться администраторами, кривых рук там быть не должно (как есть - смотрите сами, кто там вам ломал ЦС, какими действиями, почему и зачем, и насколько сильно его за это бить - тоже). Про альтернативы:
Какая такая проблема сложности PKI? Сложно создать CRL и добросить его до сервера? Сложно мониторить истечение сертификатов? (openssl x509 -enddate) Сложно держать его несломанным? Грубо говоря, семь бед - один backup.
"Голый" IPsec?! Он хорош для перманентных подключений через белые IP, и неизменяемых настройках пробрасываемых сетей. Применять его для подключения бегающих клиентов как минимум нелогично. L2TP/IPsec - вариант, но наши "доблестные" РКП его режут нещадно. Да, не вариант, но то, что он вообще тут появился, не подходит под описываемый сценарий использования VPN. 3, 4 - да, инфраструктура VPN должна быть "своей" вместе с центром доверия - но задачи управления им с вас не снимаются.
Проблемы настройки WG vs OpenVPN:
Firewall - смешно. Вы же проверяете подключение до того, как выставить сервер в прод, да? (ДА?!)
IPv4 forwarding - вообще аксиома, VPN-сервер, любой, является роутером и форвардить IPv4 обязан. (IPv6 не забудьте, кстати, если настраивали, он отдельно включается)
Ну, keepalive есть и в OpenVPN, но да, нужен.
Добавление - ну ОК, а удаление?
Итого: Можно было обойтись перенастройкой OpenVPN с тем же эффектом (ну, минус оверхэд, от него не уйти).
О, вот это я понимаю — комментарий "по существу". Спасибо, коллега vesper-bot, приятно видеть такой детальный разбор!
Давайте пройдемся по пунктам. Вы абсолютно правы во многих технических деталях, но, кажется, мы смотрим на них с разных "колоколен". Я в статье описывал переход не с идеально настроенного OpenVPN, а с типичного, исторически сложившегося.
1. Про PKI, ключи и "обвязку"
"Управление CA - хотя и неприятно, но можно сделать на вменяемом уровне... CRL... Обновление сертификатов..." "Сложно создать CRL? Сложно мониторить истечение?"
Нет, не сложно. Но всё, что вы перечислили — cron для CRL, отдельная (в идеале offline) ВМ для CA, скрипты для мониторинга openssl x509 -enddate — это и есть та самая "обвязка". Это еще одна система, которую нужно поддерживать, бэкапить и мониторить.
"если серт рано или поздно истечёт, то ключ [WG] - нет."
Это самый сильный ваш аргумент, и это 100% правда. Это известный трейд-офф. Но мы решили эту проблему "административно" через GitOps:
Выдача ключа: Новый сотрудник создает MR, добавляя свой публичный ключ в YAML-файл.
Отзыв ключа (удаление): Увольнение? git rm строки из vars.yml -> MR -> раскатка Ansible. Всё. Наш Git-репозиторий — это и есть наш "центр доверия" и "журнал аудита". Он проще, чем PKI.
2. Про "Руки", UDP и auth-gen-token
"А что это у вас кто попало лазает в easyrsa кривыми руками?"
Золотые слова! Это была именно организационная боль. easyrsa валялся на самом VPN-сервере, и в него ходили несколько админов. Да, это "неправильно". Но это была реальность. WG, с его простой моделью "ключ на клиенте, public-key на сервере", просто исключает эту проблему как класс.
"OpenVPN прекрасно умеет работать по UDP... что мешало перенастроить?" "Проблема разрыва... решается параметром auth-gen-token"
Ничего не мешало. Вы абсолютно правы. Можно было перенастроить OVPN на UDP. Можно было вкрутить auth-gen-token. Можно было вынести CA на отдельную ВМ и автоматизировать CRL.
Но в сумме это всё — «прикручивание фич» к старому комбайну. Мы просто решили, что взять новый, более простой инструмент (где UDP и "бесшовность" — это база, а не опция) и построить вокруг него прозрачный GitOps-процесс — в 2025 году уже проще, дешевле и надежнее.
3. Про "смешные" грабли
"Firewall - смешно. Вы же проверяете... да?" "IPv4 forwarding - вообще аксиома..."
Конечно! =) Вы правы, для опытного инженера это аксиомы. Но статья рассчитана и на "начинающих сисадминов". И эти два пункта — 90% всех проблем "почему мой WG не работает?" на StackOverflow. Я счел своим долгом включить их, чтобы сэкономить кому-то пару часов дебага.
Итого:
Вы абсолютно правы: можно было обойтись перенастройкой OpenVPN. Но статья не о том, что OVPN нельзя заставить работать хорошо. Она о том, что цена поддержки "хорошо настроенного OVPN" (со всей его PKI-обвязкой) оказалась для нас выше, чем цена поддержки "хорошо настроенного WireGuard" (который, по сути, один conf + один vars.yml в Git).
Спасибо за то, что заставили копнуть глубже!
Уже почти 3 года, с января 2023 года, OpenVPN 2.6.0 умеет работать по ключу и отпечатку (как и WireGuard).
Вот одна из статей https://tavda.net/openvpn
Поддерживать список фингерпринтов - маета, и кажется, без рестарта сервера не подправить. Куда проще crl-verify по выпуску заданным ЦС. Правда, при работе по фингерпринтам клиент себе сам сможет создать серт, то есть приватные ключи не передаются по сети, что есть плюс. Но доверие фингерпринту меньше, чем сертификату, SHA collision теоретически может быть (хотя не слышал про коллизию на SHA256 или выше).
Что подразумевается под передачей приватного ключа по сети?
Например, отправка конфига с вшитым приватным ключом по электронной почте. В самих алгоритмах TLS естественно приватные ключи не передаются.
Если используется "взрослый" ЦС, там есть и возможность сгенерировать серт по шаблону, и возможность подать CSR, сгенерировав ключевую пару на клиенте, а в обычной работе с easyrsa все действия с ключевой информацией выполняются на сервере ЦС и приватный ключ как-то надо выдать клиенту, кому делается сертификат.
export-p12 (кажется так в easy-rsa) в помощь. Можно inline в виде base64 в конфиг, можно отдельно передавать для импорта в хранилище (windows cert store, mac keychain, android keystore. В ios в openvpn connect куда-то под себя) с вводом пароля для импорта.
Еще есть вариант использовать bepasty (со сроком жизни файла) или других аналогов пастбина для передачи конфигов.
При наличии gitlab/forgejo или какой-то еще приблуды с oci registry есть oras cli. Накручиваем пайплайн и вот она - машина для pki, которая явно бэкапится.
15 лет юзаю openvpn, сначала серты делал руками, последние 10 лет перевел выпуск сертификатов в автоматический режим через letsencrypt+ansibletower+zabbix, авторизация доменная, ссд клиента кастомно меняются редко и это , больше исключение из правил, сам сервер виртуальный и вообще их штук 5, в разных геолокациях, стоит за роутером, клиент может выбрать тип подключения tcp udp и локацию с минимальными задержками, доп маршрутизация обеспечивается роутером rip+ospf. Получение доступа в сеть компании заключается в простом таске в джиру хочу удаленку, инструкция с конфигом готовым на Вики, админ просто добавляет клиента в группу доступа. Никакой боли.
OpenVPN пока не блокируется у нас - а вот WG уже частенько. Не опасаетесь остаться без рабочей сети?
для tailscale есть опенсорсная замена контрол плейну, headscale
1) Года 4 назад отказался от easy-rsa и накрутил в ансибле нужные рычаги openssl и ямлы.
2) CRL.pem выкинул и использую crl-verify dir, куда кладется файл с именем равным серийнику серта. Дало возможность без особых танцев проводить временную блокировку подключения.
3) Подкрутил на сервере txqueuelen (в дефолте он сотка) и sndbuf/rcvbuf.
4) Для пушей использую client-config-dir - каждому пользователю улетает только то, что надо именно ему.
5) Поигрался с cipher - оставил только AEAD алгоритмы.
6) Отказался от rsa в пользу ec. Соответственно dh заменил на ecdh. Да, серты пришлось постепенно перевыдавать.
Возможно дойдут руки поиграться с их Data Channel Offload, который выносит крипту из юзерспейса, но пока производительность устраивает и так.
1 - получается, переизобрели easyrsa, но на другой кодовой базе.
2 - интересная идея, при работе со стандартным ЦС такой опции не предусмотрено.
3 - а на сколько, и почему?
4 - вот это поддерживать надо, и зависит от конфига. Не пойму пока что, что туда кидать, за исключением одного клиента, у которого за openvpn-клиентом подсеть, куда нужен доступ из сети за сервером - у меня там конфиг с iroute.
5 - классно)
6 - тоже хорошо. Однако easyrsa можно докрутить до того, что его ЦС будет работать именно с эллиптической криптографией (set_var EASYRSA_ALGO ec; set_var EASYRSA_CURVE secp384r1)
1) скорее избавился от обертки на баш для дерганья openssl и можно извращаться с передачей контента в openssl в стиле -in <aws s3 cp filename -) без сохранения чувствительных данных на диске
2) это описано в официальном мане openvpn. Pem перечитывается раз в час, если правильно помню, а в dir смотрит при попытке подключения. Таким образом при наличии файла и посланного kill в менеджмент сокет получается выбить сессию с минимальным лагом и без необходимости рестарта самого сервиса.
3) txqueuelen 1000, как и у eth. Буферы на сервере надо подбирать исходя из ресурсов машины и наличия тюна сетевухи. Клиенту пушил 0, чтобы использовались оптимальные значения его ОС. Почему - для лучшей утилизации канала.
4) пушить туда можно фиксированный ip, маршруты, dns сервера, домены для резолва. Тоже есть в мане. Было актуально для split-dns, но тут есть нюансы в разных клиентах. В версии 2.7 обещают это переосмыслить, но пока все в бете.
5) прожевывается легче, чем старый добрый aes-cbc/ctr.
6) можно, но не очевидно. Дергать модуль shell с конкретными флагами openssl было более наглядно.
Ну и для кучи - отключать сжатие или ставить compress stubv2 для совместимости со старыми клиентами (сами разрабы рекомендуют для секьюрности).
В итоге синтетика с локальным спидтестом при использовании udp выдавала метров 250-300 сидя на вайфае, при провайдерском тарифе 500
UPD. Про crl немного попутал. Он считывается при новом подключении или при пересогласовании уже имеющейся сессии, а там дефолт час. Т.е можно провернуть kill и с crl.pem для быстрого блока. Только я бы дергал апдейт не кроном, а какой-то тулзой, умеющей в inotify/fsevents типа lsyncd, если использовать easy-rsa на отдельной машине, а не крутить пайплайны
Только не пытайтесь это использовать в России. WG активно режется РКН.
Советую попробовать Netbird. Полностью open-source решение и работает отлично. Она построена на wireguard.
Как уже выше написали, у tailscale есть классная open source замена - headscale, но у них нет своих собственных клиентов, приходится пользоваться клиентами tailscale, а с ними в РФ уже проблемы возникают. По поводу того что WG нещадно блочат провайдеры, есть реальный кейс когда заблочили ipsec до AWS, а WG без проблем работает, причём не только до AWS, но и до hetzner. В целом, по поводу использования голого WG для клиентов весьма специфический кейс. Для небольшой команды наверное ок, в компании от 100 и более человек есть огромная вероятность что создавать ключи и MR будет один человек, потому что пользователи либо не смогут, либо не захотят это делать. И тут уже проще какой-нибудь open source pritunl развернуть, тем более что там и WG тоже есть из коробки.
"Статичный" WG внутри страны для связки серверов и РОУТЕРОВ в сетку, второй "динамический" (с радиусом) WG для доступа людей к полученной инфраструктуре, ибо WG сам по себе хреново может в сегментацию - обязательно с файрволом и логами. Архитектура безопасности.
А вот для связи с заграницей - кроме ovpn ничего не получилось. Да - там нет никакого важного контента и БД, даже телеметрию нельзя обрабатывать и хранить. Максимум - репозитории без конфигов, но связь нужна :(
OpenVPN более гибок в настройке, с приходом DCO по скорости с WG не очень большие отличия.
PKI достаточно прост, как писали другие можно без проблем выделить виртуалку и на ней организовать CA с дальнейшей синхронизацией итоговых файлов на VPN сервера, благо ccd и crl применяются без рестарта сервера OpenVPN.
Из того что конкретно использую и чего нет в WG единственное это авторизация в LDAP при подключении, ну и всё таки полноценные логи рулят, особенно когда начинаются проблемы.
Ну и чтобы не гонять весь клиентский трафик через "защищённый бастион" лучше пушить нужные подсети клиентам, как централизовано, так и в индивидуальном порядке если нужно.
Подскажите, какой есть хороший клиент для WG? У нативного есть баги: периодически отваливается служба и ВПН вроде работает но в окне wg клиента на windows все подвисло и ничего нельзя нажать (помогает перезапуск службы). И ещё баг не всегда стартует при старте win
Мало того, он еще и active даже если ни одного ответа от сервера не получил. И это порядком ПОЛЬЗОВАТЕЛЕЙ сбивает с толку. Ну т.е. статус зеленый, а нифига не работает.
В целом ощущения противоречивые. Пока работает - норм. Если проблемы - найти их не так уж быстро/просто.
Мало того, он еще и active даже если ни одного ответа от сервера не получил
Таков UDP, это фундаментальное ограничение WireGuard. Это так, к слову.
Кстати, все ваши баги я встречал. Но в итоге перешёл на XRay (Remnawave): и РКН идёт лесом, и доступ к инфраструктуре имеется. Но это совсем другая парадигма работы с VPN "как прокси", само собой. Надо наизусть знать конфиг и устройство XRay - те самые inbound -> routing -> outbound.
Про WireGuard как страшный сон забыл.
Создает Merge Request в наш репозиторий, добавляя свой public_key и имя в YAML.
Да-да, прямо вижу как Бухгалтер генери ключ и пушит MR...
Вопрос к граблям реальности: будет ли это работать в Windows XP?
Столкнулся с тем, что OpenVPN сервер обновился внутри pfSense, и теперь BF-CBC не считает за алгоритм. А кастомный клиент для win XP заставляет перезагружаться сервер OpenVPN в цикле, если к нему подключится.
Судя по статье как будто очень просто всё (за исключением пуша Ростов). Хочу попробовать. Но вдруг кто-то уже сталкивался?
Все бы здорово но у wireguard есть нету кучи всего что есть в openvpn что добавляет ему гибкости. Да даже банально выбор между TCP и UDP часто нужен или выбо между tun tap, а так же DHCP и доп авторизация.
А еще у openvpn есть киллерфича которая позволяет его маскировать - это возможность указать прокси . таким образом вы можете его запаковать в vless.
А можно вот это чуть подробнее?
Всё банально и просто. Я не супер сисадмин, но когда РКН начал шатать мой OpenVPN пришлось искать решения, тем более что wireguard как красная тряпка вообще.
И я нашёл Vless+reality, который ставится через 3x-ui. Но есть проблема - он работает как прокси, и там нет ip адресов у узлов, как у OpenVPN, что не позволяет создать vpn сеть. Как замечательно что OpenVPN на tcp имеет параметр в конфиге клиента который позволяет использовать прокси.
Вы ставите на клиент и на сервер xray и OpenVPN, далее на клиенте настраиваете классический xray конфиг который выступает как прокси на локалхосте ( обычно для ваших браузеров ), а потом ставите клиент OpenVPN и в параметрах клиента указывается ваш прокси 3x-ui на локалхосте, и вуаля - у вас OpenVPN внутри Vless+reality, идеально замаскированный по https снаружи для РКН. Скорость не ахти, но устойчивый к блокировкам. С WG так тоже можно сделать, но через другой инбаунд, и это тяжелее.
На хабре таких мануалов нет, но мне это как то самому в голову пришло, я это протестил и получилось.
Если вам было это полезно, поставьте лайк, может дорастёт рейтинг до возможности публиковать статьи.
WireGuard аналогично, только уже со стороны ядра XRay, а не со стороны WireGuard. В таком случае роли меняются и балом правит уже тот, кто раздаёт VLESS.
1) Для тех, кто не хочет EasyRSA, напомню, что OpenVPN 2.6.0 выпущен аж в январе 2023 года. И он отлично умеет работать по ключам и отпечаткам.
Вот одна из статей https://tavda.net/openvpn
2) Хорошо, когда конечными клиентами являются персональные устройства. А если это филиалы с полсотней сетевых устройств?
3) При не идеальном эфире для сотовой связи, кои можно наблюдать во многих торговых центрах страны, udp туннель просто мертв. Только tcp спасает ситуацию, хотя и проседает по скорости.
4) Имеем множество клиентов в регионах страны, где без mssfix туннель вообще не работает. (У WireGuard не обнаружили такой возможности).
When the --peer-fingerprint option is used, specifying a CA with --ca or --capath is optional. This allows the he --peer-fingerprint to be used as alternative to a PKI with self-signed certificates for small setups.
Вот тут я согласен с разработчиками. Хорошо, что есть возможность, но при сетапе на пару-тройку сотен динамично меняющихся людей ( условный колл-центр) это выглядит как ад. Особенно при схеме выдает иб, настраивает на тачках техпод, а ты отдаешь инфру и пайплайн.
Поднял на домашнем роутере Wireguard, и было время, когда РКН блочил по выходным весь Wireguard трафик, хотя всё внутри страны работает) Сейчас уже норм вроде, не блокируют (пока ещё).
Так что если в РФ, то желательно сразу готовить лыжи в виде Amnezia WG. Суть та же, что и у Wireguard, только в заголовки пакетов добавляется всякий "мусор", понятно зачем.
В общем, использовать ванильный Wireguard, но рядом ещё держать бы вот такой резерв. Это лучше, чем все разом потеряют доступы. Ну, или тот же Open VPN в заначке держать, а то и Open VPN от Amnezia (тоже есть).
Amnezia WG. Суть та же, что и у Wireguard, только в заголовки пакетов добавляется всякий "мусор", понятно зачем.
Не рекомендую как раз из-за этого поведения. AmneziaWG просто ни на что не походит, а по-правильному надо притворяться легитимным HTTP. Потому что, когда будут резать всё на всех уровнях, оставляя лишь HTTP, AmneziaWG отвалится и не встанет.
Как перевалочный пункт - ещё можно, особенно внутри страны. Но, в конце концов, все придут к VLESS с XTLS-Reality (а мажоры - к VLESS с xHTTP).
то желательно сразу готовить лыжи в виде Amnezia WG
Против этого в конце октября уже испытали средство - отрубили доступ ко всем популярным у пользователей VPN зарубежным хостингам.
Например, у сверхпопулярной Aeza остался доступным только 22 порт.
Как в WG решается split horizon? Вот, в openvpn можно добавить домен, который должен резолвить из впн-а. А вот в WG я такой фичи не видел.
Спасибо за статью. Но если можно добавлю из опыта своего. У клиентов бывают свои принтеры на вай-фай например и тогда 0.0.0.0/0 отваливают. Равно как и весь интернет трафик заворачивается в рабочую сеть.
Мое мнение что 0.0.0.0/0 это не паранойя, а доп проблематика для клиентов. По мне проще заворачивать только рабочий трафик в туннель.
Берем обычную Ubuntu 22.04 LTS / Debian 12
Берем обычный Mikrotik Cloud Hosted Router и получаем безопасность, веб/winbox панель для удобного мониторинга, удобное управление по API и никакого оверизобретения костылей в красноглазом стиле DevOps.
VPN для админа, а не админ для VPN: Как мы убили OpenVPN и построили всё на WireGuard