WireGuard — прекрасный VPN будущего?
Наступило время, когда VPN уже не является каким-то экзотическим инструментом бородатых сисадминов. Задачи у пользователей разные, но факт в том, что VPN стал нужен вообще всем.
Проблема текущих VPN решений в том, что их тяжело правильно настроить, дорого обслуживать, а так же в них полно legacy кода сомнительного качества.
Несколько лет назад канадский специалист по информационной безопасности Jason A. Donenfeld решил, что хватит это терпеть, и начал работу над WireGuard. Сейчас WireGuard готовится к включению в состав ядра Linux, он даже получил похвалы от Линуса Торвальдса и в американском сенате.
Заявленные преимущества WireGuard над другими VPN решениями:
Неужели найдена серебрянная пуля? OpenVPN и IPSec пора закапывать? Я решил с этим разобраться, а заодно сделал скрипт для автоматической установки личного VPN сервера.
Принципы работы
Принципы работы можно описать примерно так:
Вся основная логика WireGuard занимает менее 4 тысяч строк кода, тогда как OpenVPN и IPSec имеют сотни тысяч строк. Для поддержки современных криптоалгоритмов предлагается включить в состав ядра Linux новый криптографический API Zinc. В данный момент идет обсуждение, насколько это удачная идея.
Производительность
Максимальное преимущество в производительности (по сравнению с OpenVPN и IPSec) будет заметно на Linux системах, так как там WireGuard реализован в виде модуля ядра. Кроме этого поддерживаются macOS, Android, iOS, FreeBSD и OpenBSD, но в них WireGuard выполняется в userspace со всеми вытекающими последствиями для производительности. Поддержку Windows обещают добавить в ближайшем будущем.
Результаты бенчмарков с официального сайта:
Мой опыт использования
Я не эксперт по настройке VPN. Однажды настраивал OpenVPN ручками и это было очень муторно, а IPSec даже и не пытался. Слишком много решений нужно принимать, очень легко выстрелить себе в ногу. Поэтому я всегда пользовался готовыми скриптами для настройки сервера.
Так вот, WireGuard, с моей точки зрения, вообще идеален для пользователя. Все низкоуровневые решения приняты в спецификации, поэтому процесс подготовки типичной VPN инфраструктуры занимает всего несколько минут. Нафакапить в конфигурации практически невозможно.
Процесс установки детально описан на официальном сайте, отдельно хочется отметить отличную поддержку OpenWRT.
Генерируются ключи шифрования утилитой wg :
Далее, нужно создать серверный конфиг /etc/wireguard/wg0.conf со следующим содержанием:
и поднять туннель скриптом wg-quick :
На клиентской машине, создать конфиг /etc/wireguard/wg0.conf :
И точно так же поднять туннель:
Осталось настроить NAT на сервере, чтобы клиенты могли выходить в Интернет, и все готово!
Такую простоту использования и компактность кодовой базы удалось достичь за счет отказа от функционала дистрибьюции ключей. Здесь нет сложной системы сертификатов и всего этого корпоративного ужаса, короткие ключи шифрования распространяются примерно как SSH ключи. Но в связи с этим возникает проблема: WireGuard будет не так просто внедрять в некоторых уже существующих сетях.
Из недостатков стоит отметить, что WireGuard не заработает через HTTP proxy, поскольку в качестве транспорта есть только протокол UDP. Возникает вопрос, возможно ли будет обфусцировать протокол? Конечно, это не прямая задача VPN, но для OpenVPN, например, существуют способы маскировки под HTTPS, что помогает жителям тоталитарных стран полноценно пользоваться Интернетом.
Выводы
Подводя итог, это очень интересный и перспективный проект, можно уже сейчас использовать его на личных серверах. Какой профит? Высокая производительность на Linux системах, простота настройки и поддержки, компактная и читабельная кодовая база. Однако, бросаться переводить комплексную инфраструктуру на WireGuard еще рано, стоит подождать включение в состав ядра Linux.
Для экономии своего (и вашего) времени я разработал автоматический установщик WireGuard. С его помощью можно поднять личный VPN для себя и своих знакомых даже ничего в этом не понимая.
WireGuard. How it was
Привет. Меня зовут Алексей, и я System Infrastructure Engineer в inDriver. В этой статье на конкретных кейсах объясню, почему WireGuard — отличная VPN-система для работы, в чем разница использования ее утилит, и что надо помнить, когда с ними работаешь. Прошу под кат!
С чего все началось
Исторически сложилось, что часть сервисов в inDriver находятся на арендованных серверах. Для защиты трафика между серверами в одном дата-центре мы решили зашифровать его. Изначально рассматривали следующие решения:
Вот сравнительный анализ, где N — количество серверов:
Количество соединений в полносвязной топологии
В итоге мы остановились на WireGuard.
И понеслось
Во время тестирования появилась проблема: информации по полносвязной топологии чуть меньше, чем ничего. Несмотря на это, построить ее просто: нужно обменяться своими параметрами (endpoint_ip, allowed_ips, public_key) с другими серверами и получить их в ответ. Состряпать конфигурации не составило труда. А еще первоначально проблем не наблюдалось, потому что использовалась утилита wg-quick.
Утилита wg-quick может работать только с файлом конфигурации. Файл конфигурации состоит из полей:
PrivateKey — приватный ключ. Не путь к ключу, а именно его содержимое. Обязательно должно присутствовать.
ListenPort — порт, на котором работает WireGuard. Если нет, выбирается случайно.
FwMark — маркировка исходящего трафика.
Address — IP-адреса, которые будут назначены интерфейсу.
DNS — DNS-адреса (через запятую или несколько раз указать DNS). Требует наличие пакета resolvconf! Если нет, DNS не добавляются.
MTU — значение MTU для интерфейса. Если нет, MTU не изменяется.
Table — таблица маршрутизации, куда будут добавлены маршруты для WireGuard. Если нет, используется таблица main.
PreUp, PostUp, PreDown, PostDown — скрипты, которые будут выполняться перед и после подключения, перед и после отключения соответственно. Можно указывать несколько скриптов. Выполняться они будут в порядке, описанном в файле.
SaveConfig — флаг сохранения всех изменений в файл конфигурации.
Каждый пир должен быть представлен отдельной секцией [Peer] со следующими полями (совпадающими с параметрами запуска wg set peer. ):
PublicKey — публичный ключ. Обязательно должен присутствовать.
PresharedKey — дополнительный ключ шифрования. Если нет, дополнительное шифрование не используется.
AllowedIPs — список разрешенных подсетей. Можно указывать каждую сеть через запятую, а можно несколько раз указать это поле. Если нет, никакая сеть не закреплена за пиром.
Endpoint — IP-адрес или имя пира с обязательным указанием порта. Можно не указывать.
PersistentKeepalive — об этом упомяну отдельно.
Чтобы полносвязная топология задышала, нужно выполнить два условия:
У каждого сервера в пирах должны присутствовать сведения обо всех серверах.
Для корректной работы в allowed-ips следует указывать адрес соседа (ip/32).
Достаточно пользоваться утилитой wg-quick.
В списках пиров все серверы дата-центра.
Кажется, пора открывать шампанское! Но не все так просто.
Проблема 1. Несколько дата-центров
А если добавим еще пару-тройку дата-центров? Есть 3 решения:
Тупо добавить серверы из других дата-центров в общую кучу. Нам этот вариант не подошел, так как не у всех серверов есть внешний сетевой интерфейс.
Создать отдельное подключение для сети внутри дата-центра и отдельное соединение для связи дата-центров между собой. Это тоже не наш метод — 2 сетевых подключение на 2 больше, чем хочется.
Соединить дата-центры между собой, используя существующее соединение! Бинго!
Шлюзы в дата-центрах нужно соединить между собой, используя внешние IP-адреса и дополнительно передавая подсеть дата-центра в список allowed_ips (по-нолановски, правда?).
Для шлюзов дата-центра надо добавить в пиры другие шлюзы дата-центра и передать свою подсеть им в allowed_ips.
Проблема 2. Как добавить сервер, не выключая сетевой интерфейс?
Оказалось, wg-quick не имеет возможности применить новую конфигурацию. Попробуем сделать это через утилиту wg. Но и тут не все так просто!
В чем прелесть этой утилиты?
1. Для использования не обязательно наличие файла конфигурации. Для работы достаточно создать новый интерфейс типа WireGuard.
Примечательно, что имя интерфейса можно задать любое, исходя из практики именования сетевых интерфейсов. Выходит, к этому интерфейсу применимы все действия, которые можно проделывать с любым интерфейсом (например, менять MTU). Также можно вывести только WireGuard-интерфейсы командой:
2. Не требуется использование конфигурации. Все можно настроить вручную, используя команду wg set. Параметры можно указывать по очереди или вместе.
Коротко о параметрах этой команды:
1. listen-port
UDP-порт, на котором будет работать сервер WireGuard. Если не указывать, при каждом новом запуске сервиса будет выбран случайный порт. Это усложняет настройку сервера.
Важно помнить, что одновременно на одном порту может работать только один сервис! Если поднимать несколько WireGuard-подключений, каждому следует выделять отдельный порт.
2. fwmark
Маркировка исходящего трафика. Мне было лень искать в nftables правила маркировки, но для iptables правил не создается. Экспериментально выяснил, что помечаются пакеты в таблице FILTER цепочки OUTPUT. Следует помнить, что если приложение лезет своими битами в маркировку пакета (например, k8s), это может поломать нормальную работу WireGuard. Тогда следует задуматься о необходимости использования этого параметра.
3. private-key
Приватный ключ. Немного поэкспериментировав, я выяснил, что это просто массив из 32 байт, закодированный в base64. По сути, выполнение скрипта на python3:
Эквивалентно выполнению команды:
Для того, чтобы впихнуть ключ в WireGuard и избежать создание файла, можно применить следующее:
4. peer
Работа с пирами. Дополнительные параметры:
remove — удаление пира из списка. Полностью прекращает работу с данным пиром.
preshared-key — ключ для дополнительного шифрования трафика. Да, требуется наличие файла.
— показывает, с какого адреса и порта ждать подключение.
persistent-keepalive — об этом чуть попозже.
allowed-ips / [, / ]. — список сетей, которым предназначается трафик. Если в WireGuard-интерфейс попадает пакет, то пир, которому перенаправляют пакет, берется из этого параметра. Если в интерфейс попадет пакет, а ответственного пира нет, пакет никуда не пойдет. Для icmp ловил отлуп вида “Required key not available”.
Хорошо! А как сделать так, чтобы не пришлось вручную вводить информацию о пирах? Ответ: сформировать файл конфигурации. Следуя инструкциям, в нем должна быть одна секция [INTERFACE] со следующими полями:
PrivateKey — приватный ключ. Не путь к ключу, а именно его содержимое. Обязательно должно присутствовать.
ListenPort — порт, на котором работает WireGuard. Если нет, выбирается случайно каждый раз.
FwMark — маркировка исходящего трафика.
Каждый пир должен быть представлен отдельной секцией [Peer] со следующими полями (совпадающими с параметрами запуска wg set peer. ):
PublicKey — публичный ключ. Обязательно должен присутствовать.
PresharedKey — дополнительный ключ шифрования. Если нет, дополнительное шифрование не используется.
AllowedIPs — список разрешенных подсетей. Можно указывать каждую сеть через запятую, а можно несколько раз указать это поле. Если нет, никакая сеть не закреплена за пиром.
Endpoint — IP-адрес или DNS имя пира с обязательным указанием порта. Можно не указывать.
PersistentKeepalive — терпение, чуть ниже все расскажу.
Чтобы не марать руки, можно сгенерировать файл автоматически, используя метод showconf (выводит текущую конфигурацию):
Также есть команды setconf, addconf и syncconf. Об этом поподробнее:
setconf — применяет конфигурационный файл.
addconf — добавляет конфигурацию к текущей. В файле конфигурации не всегда должна присутствовать секция [Interface]. Будет выполняться wg set для каждого пира в файле.
syncconf — синхронизирует текущую конфигурацию и файл конфигурации. Применяет разницу. Если в текущей конфигурации ListenPort = 51820, а в файле он не указан, после применения получится случайный порт, так как изменилось значение. Это касается и приватного ключа! Будет выполняться wg set peer только для тех пиров, которые изменили значение.
Для просмотра информации о соединениях можно воспользоваться командой:
Мы получаем много информации, поэтому я чаще пользуюсь командой:
Чтобы после перезапуска сервиса все изменения сохранились, придется сохранять изменившуюся конфигурацию:
Заметил, что после изменений, сделанных утилитой wg служба wg-quick@$WG_IFACE перестает работать: остановка службы не происходит, а попытка запуска завершается ошибкой «Данный интерфейс существует».
Для восстановления конфигурации используется wg-quick, для изменения — wg.
В списках пиров все серверы дата-центра.
Для шлюзов дата-центра добавить в пиры другие шлюзы дата-центра и передать свою подсеть им в allowed_ips.
Все получилось — интерфейс поднялся, данные передаются. Ура!
Проблема 3. Маршрутизация и утилита wg
Все новые пиры на месте, но доступа к ним нет. Что же случилось? Все просто: утилита wg не следит за маршрутами, за ними надо следить самостоятельно!
Все надо делать самому: следить за маркировкой пакетов, маршрутами, правилами файрвола, заворачивать трафик. Для того, чтобы добавить пир через утилиту wg, нужно сделать это вручную и убедиться, что он есть в таблице маршрутизации. И после этого все заработает.
Выход был найден! Выяснилось, что скрипт:
Выполняет всю пыльную работу за инженера!
Значит, системе не обязательно знать, куда уходит пакет. Главное, что он падает в интерфейс WireGuard, а что, как, кому и куда — решает сам VPN! Вот она — магия WireGuard!
Есть отдельный скрипт для добавления маршрутов.
При изменении конфигурации нужно запускать скрипт добавления маршрутов.
Почти что без проблем
Ключевое слово — почти. Первая проблема возникает, если маршрут по умолчанию идет через WireGuard, а обращение — на внешний интерфейс. Объясню на пальцах:
Клиент обращается к серверу по внешнему адресу exIP.
На сервер приходит пакет на адрес exIP.
Сервер формирует ответный пакет.
Согласно таблице маршрутизации пакет отправляется… в интерфейс WireGuard.
Шлюз WireGuard пересылает пакет, используя wgIP-адрес.
Клиент получает ответ от сервера с IP-адреса wgIP и… отбрасывает его, так как он не ждет от него ответа. Ответ ожидается от exIP.
Клиент уходит в закат, не дождавшись ответа.
Ленивый инженер скажет всем клиентам отключить rp_filter, но эта история не про нас. Можно маркировать пакеты с помощью файрвола, а потом маркированные пакеты заворачивать в отдельную таблицу маршрутизации. Но я слишком ленив, чтобы ковырять еще и его.
Выход: только хардкор! Только iproute2! Достаточно заворачивать исходящий трафик с определенного адреса в отдельную таблицу маршрутизации! Для адреса 172.100.0.2 и маршрутизатора 172.100.0.1 нужно выполнить 2 действия:
Эти команды создадут дополнительную таблицу маршрутизации с номером 10000 и завернут весь исходящий трафик с IP-адреса 172.100.0.2 через маршрутизатор 172.100.0.1, что нам и нужно.
Это нужно добавить в скрипт маршрутизаци, чтобы правила применялись при поднятии интерфейса WireGuard.
Еще одна проблема возникает при мониторинге состояния WireGuard. Оказалось, что если сервер A не обращается какое-то время к серверу B, handshake не происходит! Как быть?
PersistentKeepalive — a seconds interval, between 1 and 65535 inclusive, of how often to send an authenticated empty packet to the peer for the purpose of keeping a stateful firewall or NAT mapping valid persistently.
На деле же раз в указанный промежуток пиру посылается пакет нулевого размера. Это позволяет поддерживать соединение постоянно открытым.
Заметил, что при отсутствии этого параметра возникал неприятный баг. При отсутствии соединения, даже если пинговать пир, рукопожатия не возникало, пока вручную с обратной стороны не начать пинговать пир в ответ. Сервер пытается установить рукопожатие, а с той стороны ответа нет, так как взаимодействия с сервером отсутствует. Чтобы такого не происходило, нужно использовать PersistentKeepalive на всех хостах или на центральном шлюзе.
Принято! Выходит, что:
PersistentKeepalive не должен быть равен нулю.
Резюме
Моей изначальной целью было поглубже раскрыть, что такое WireGuard и что надо помнить, когда с ним работаешь. Данная статья — результат тщательного исследования работы этого VPN.
Исследование работы WireGuard мы начали в прошлом октябре, а переход на него — в этом феврале. Следующий подход с основательным зубрением этого предмета ожидается, когда WireGuard будет поставляться из коробки со всеми ОС, включая мобильными. Буду изучать, как менее проблемно добавить к этой топологии пользовательские подключения.
Спасибо, что дочитали статью до конца. С радостью отвечу на ваши вопросы в комментариях.
Что лучше выбрать: Wireguard или OpenVPN? Любимый VPN Линуса Торвальдса
Технологии VPN редко становятся объектами пристального внимания: есть и есть. Создатель Wireguard Jason A. Donenfeld оказался везунчиком после нетипичной для Линуса Торвальдса резко хвалебной оценки качества кода.
Can I just once again state my love for it 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.
Шифрование: отличия Wireguard от OpenVPN
Wireguard исповедует минималистский и безапелляционный подход к шифрованию, преднамеренно исключив гибкость и альтернативу выбора протоколов, так как это слишком затратно. Если нет выбора протоколов, нет и процесса согласования, в котором традиционно находят дыры безопасности. Кроме того SSL/TLS уязвимости, идущие ровным потоком, также не в пользу богатства выбора.
Протоколы шифрования Wireguard
Протоколы шифрования OpenVPN
OpenVPN поддерживает множество криптографических алгоритмов, используя библиотеку OpenSSL. Более точно, для шифрования и аутентификации используются следующие алгоритмы.
aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb
aes-256-cbc aes-256-ecb aria-128-cbc aria-128-cfb
aria-128-cfb1 aria-128-cfb8 aria-128-ctr aria-128-ecb
aria-128-ofb aria-192-cbc aria-192-cfb aria-192-cfb1
aria-192-cfb8 aria-192-ctr aria-192-ecb aria-192-ofb
aria-256-cbc aria-256-cfb aria-256-cfb1 aria-256-cfb8
aria-256-ctr aria-256-ecb aria-256-ofb base64
bf bf-cbc bf-cfb bf-ecb
bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc
camellia-192-ecb camellia-256-cbc camellia-256-ecb cast
cast-cbc cast5-cbc cast5-cfb cast5-ecb
cast5-ofb des des-cbc des-cfb
des-ecb des-ede des-ede-cbc des-ede-cfb
des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb
des-ede3-ofb des-ofb des3 desx
idea idea-cbc idea-cfb idea-ecb
idea-ofb rc2 rc2-40-cbc rc2-64-cbc
rc2-cbc rc2-cfb rc2-ecb rc2-ofb
rc4 rc4-40 rc5 rc5-cbc
rc5-cfb rc5-ecb rc5-ofb seed
seed-cbc seed-cfb seed-ecb seed-ofb
sm4-cbc sm4-cfb sm4-ctr sm4-ecb
Для хеш сумм доступны такие функции.
Выводы по стандартам шифрования и безопасности
Архитектурно Wireguard более безопасен за счет того, что поверхность атаки значительно меньше по сравнению с OpenVPN. Тем не менее, OpenVPN считается очень безопасным и надежным, многократно пройдя независимый аудит кода. За счет этого OpenVPN выигрывает при консервативном подходе к выбору VPN-решения.
Вместе с тем отсутствие гибкости, возможности выбора способа шифрования создает значительные препятствия для использования Wireguard в корпоративном сегменте пользователей VPN. Представьте стандартную для наших ситуацию, в которой сотрудники подключаются к рабочей сети по VPN с различных устройств. В такой ситуации отсутствие гибкости и выбора создаст гораздо больше проблем, чем сможет их устранить.
Сравнение производительности
Так как Wireguard реализован в пространстве ядра, а OpenVPN в пользовательском пространстве, у первого должно быть преимущество в скорости. Связано это с тем, что пакеты постоянно копируются из одного пространства в другое и кроме того требуется постоянная фоновая служба OpenVPN.
Все это необходимо проверить на практике, к счастью есть множество замеров скорости для VPN туннелей. Для начала можно взглянуть на результаты VPN-дерби от самого автора Wireguard. Вот некоторые детали и результаты замера.
Сравнение производительности различных VPN со стороны Jason A. Donenfeld-а
В обоих тестах — на пропускную способность и время отклика ping, Wireguard значительно превзошел OpenVPN, а заодно и две вариации IPSec-а. Кроме того, во время теста на пропускную способность с использованием OpenVPN и IPSec утилизация CPU достигала 100%. В то же время использование Wireguard так сильно не загружало центральный процессор, давая тем самым возможность полностью утилизировать ресурсы сетевой карты Gigabit Ethernet.
Естественно предположить, что автор Wireguard может быть предвзятым в составлении сценариев и трактовке результатов замера производительности технологий VPN. Следовательно, имеет смысл ознакомиться с другими тестами скорости разных VPN. Благо все, что для этого нужен VPS сервер, VPN и пакет iperf3.
Но и другие подобные тесты показывают превосходство Wireguard в тестах производительности.
Сравнение производительности Wireguard и OpenVPN
Неожиданным фактом можно считать, что openvpn-tcp быстрее openvpn-udp, однако при ближайшем рассмотрении все становится на свои места. TCP-поток имеет меньше завершенных тестов, чем UDP. Во всяком случае и тут Wireguard показывает лучшие результаты производительности.
В той же серии тестов любопытно сравнение скорости VPN-соединения в зависимости от числа открытых сокетов. При росте их количества производительность Wireguard скачкообразно падает, хотя продолжает оставаться выше, чем openvpn-tcp и openvpn-udp.
Сравнение производительности Wireguard и OpenVPN в зависимости от числа открытых сокетов. TestID 0-600 соответствует openvpn-udp, 700-1200 — openvpn-tcp и 1300-1800 — Wireguard
Выводы по скорости VPN-соединения
Синтетические тесты скорости от разных авторов, с использованием пакета iperf3, позволяют предположить, что Wireguard быстрее, чем OpenVPN.
Конфиденциальность данных
VPN-протоколы уделяют гораздо большее внимание безопасности соединения, нежели конфиденциальности. Однако возможность сохранения анонимности тоже имеет значение — кому охота писать объяснительные по факту закачки учебника Oracle, или эмулятора топологии Cisco? Ничто так хорошо не выдает факт правонарушения, как IP адрес пользователя.
Настройки Wireguard в явном виде содержат IP адреса пользователей и это обстоятельство не позволит им остаться незамеченным после того, как сервером заинтересуются правоохранительные органы. Сетевой трафик прочитать, конечно, не удастся, однако можно идентифицировать самих участников защищенного соединения.
Сама настройка защищенного соединения Wireguard довольно проста. Сперва установка.
Создаем открытый и закрытый ключи.
Далее, необходимо настроить файл /etc/wireguard/wg0.conf.
Второй участник подключения должен у себя настроить такой же файл, указав в нем свой закрытый ключ и открытый ключ участника A. Для установки соединения каждая из сторон выполняет wg-quick up interface_name.
Из этого видно, что при настройке Wireguard IP адрес, либо имя узла задаются в явном виде и будут видны в системных лог-файлах и таблицах SNMP до момента перезагрузки сервера.
OpenVPN лучше защищает конфиденциальность клиентских подключений, так как не требует до установки защищенного соединения прописывать IP адреса, или сетевое имя клиентских компьютеров.
Выводы по конфиденциальности данных
В этой номинации OpenVPN имеет определенное преимущество ввиду того, что лишь Wireguard предполагает хранение IP-адреса пользователей на VPN-сервере в течение длительного времени.
Итоги: какой же VPN выбрать?
Есть огромное количество пользовательских сценариев использования VPN, и вряд ли одна и та же рекомендация будет хороша для всех. Соответственно, для разных сценариев можно выделить две группы с наиболее подходящим решением для VPN.
То лучше используйте OpenVPN.
Ну а какой VPS брать под VPN вы и так знаете.