Комментарии 124
Ну тут видите ребята — все очень субъективно и каждому своё. Но статья огонь! Спасибо! Читал с интересом
На 100-мегабитном канале результаты тестирования скорости следующие (speedtest, Wi-Fi, download/upload):
— без vpn: 91/92;
— wg: 35/29;
— ovpn: 8/7.
При этом, если подключиться к ovpn с десктопа, то скорость выдает 84/87.
Привел результаты первых же измерений, средние показатели не получал, но они близки к приведенным числам.
TP-Link Archer C7 v5, OpenWRT-SFE.
OpenVPN 10 Mbit/s
WireGuard 80 Mbit/s
Оба решения упираются в CPU маршрутизатора. Отключение шифрования в OpenVPN (насколько я разобрался как это сделать) поднимало скорость примерно до 15 Mbit/s.
Для заворачивания по списку РКН — должно полностью хватить. Если есть желания завернуть весь трафик в туннель, то скорее всего имеет смысл выбрать железку помощнее.
Для заворачивания хватит, но вот крутить по ок 2k видео уже маловато Будет. Насчёт маршрутизатора интересный факт. Видимо стандартных от провайдера уже не хватает
На моём OpenVPN тоже упирается в 10Мб/с. Жаль Wireguard нет в стоковой прошивке для теста.
На моем openwrt-роутере было недостаточно ресурсов даже для запуска openvpn. wireguard работал чуть ли не со скоростью аплинка.
Между двумя роутерами на mt7621 на OpenWRT 19.07.5 Wireguard дает 180-200mpbs (300mbps аплинк на обоих). OpenVPN оставался в районе 30mbps.
Интересно посмотреть вновь, когда в mt7621 начнут поддерживать аппаратную крипту на EIP-93. Кроме того, там в этом движке есть примитивы для IPSec, поэтому если будет не только ускорение крипты, но и аппаратная обработка пакетов IPSec, последний может оказаться самым быстрым решением.
К сожалению, Wireguard не прячет пакеты и легко блокируется.
Он решает вопросы шифрования. Прятать трафик — это о другом.
И хотя шифровать трафик и прятать трафик в некоторых случаях идет рядом — но всё же вторая задача не является целью Wireguard на сегодня, он не для этого.
Из этого видно, что при настройке Wireguard IP адрес, либо имя узла задаются в явном виде
Один из пиров может не указывать в своём конфиге Endpoint другого пира — тогда он будет назначен автоматически при его подключении (хотя залогировать подключившйся айпишник всё равно никто не запрещает)
Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя.
И адрес клиента в настройках сервера не задаётся, более того, он может меняться во время работы без разрыва соединения. Там задаётся адрес внутри VPN, но он вообще может быть внутренним и никак не выдаёт местоположение пользователя, а также публичный ключ (которого недостаточно, чтобы подключиться от имени клиента, в конфиге которого лежит приватный ключ).
Преимущество OpenVPN в том, что он поддерживает разные способы аутентификации и динамическую выдачу IP-адресов. С Wireguard вам понадобится какой-то свой сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера — а в OpenVPN это доступно из коробки. Поменялся IP на стороне пользователя — ему надо поменять конфиг, а OpenVPN просто выдаст новый.
сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера
github.com/StreisandEffect/streisand/blob/master/README-ru.md
Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя
Версию ядра проверьте. Может уже и в ядре.
А зачем вообще прописывать IP пользователя? Он должен меняться без перенастройки конфига.
Предположу, что romancelover некорректно выразился и он имел в виду IP пользователя внутри VPN-сети. В Wireguard его нужно обязательно прописать в конфиге пользователя вместе с подсетью (опция Address в секции Interface), в то время как OpenVPN-сервер способен раздавать клиентам айпишники даже динамически, да ещё и все нужные маршруты клиентам разослать — и это основная причина, останавливающая лично меня от повсеместного использования Wireguard
Я написал явно "там в конфиге задаётся адрес внутри VPN", и он задаётся статически в конфиге, поменялся IP — должен меняться конфиг и на сервере, и на клиенте. Это часто бывает неудобно.
Но в следующих версиях клиента WireGuard планируется добавить поддержку динамических адресов внутри VPN.
https://git.zx2c4.com/wg-dynamic/about/docs/idea.md
Честно говоря, я лично подключаясь к OpenVPN в новой компании, первым делом добавляю в конфиг route-nopull. Потому что не хочу, чтобы мне рассылали маршруты: во-первых это плохо из соображений безопасности (я не хочу предоставлять админам этой компании возможность перехватывать любой мой трафик по собственному желанию), и во-вторых у меня на компе 16 сетевых интерфейсов (и это не считая ещё 20 поднятых докером) многие из которых используют подсети тех же 10/8 и 192.168/16 что используются и внутри VPN компании, и присылаемые роуты тупо могут сломать мою сеть.
Если Вы ещё не видели, то может иметь смысл посмотреть на Tailscale — они вроде бы реализовали все традиционные для энтерпрайза фичи на базе wireguard.
Если тебе впн нужно включить разово, чтоб зайти на рутрекер, это немножко подбешивает.
В макоси я правда написал скриптик для Автоматора, чтобы ВГ тогглился по сочетанию клавиш. Это когда еще гуёв не было, с тех пор им и пользуюсь
network-manager имеет gui для настройки Wireguard.
Пес его знает, но в KDE5 оно есть в настройках сетевых соединений.
Может это и я дурак, посмотрю в убунте повнимательней.
В комментариях есть скрины KDE. Там gui для настройки есть.
HTTP? Не SOCKS5?
Как то пришлось использовать это, для обхода корпоративного прокси (лет 7 назад, там был Forefront TMG).
Впрочем кажется дискуссия здесь была про другое, извините.
можно взять например плагин FoxyProxy — он по шаблону урла может использоваться прокси для конкретной страницы
В отличие от OpenVPN, Wireguard не использует сертификаты X.509 и лишен сопутствующих проблем. Вместо этого Wireguard использует асимметричное шифрование с открытым и закрытым ключом.
Во-первых, сертификат Х.509, это и есть ассиметричное шифрование с закрытым и открытым ключом. Сертификат хранит открытый ключ. Во-вторых, отсутствие разнообразия способов аутентификации — это минус, а не плюс. Да, если настраивать один туннель от дома до VPS, можно и руками ключи прописать. Но для промышленных решений нужны какие-то штуки посерьёзней.
Wireguard исповедует минималистский и безапелляционный подход к шифрованию, преднамеренно исключив гибкость и альтернативу выбора протоколов
Через 10 лет поли/чача устареют и придётся вводить новый алгоритмы, а с ними и гибкость и альтернативу выбора.
а с ними и гибкость и альтернативу выбора.
Не обязательно. Достаточно передавать номер версии протокола, а используемые алгоритмы прибить гвоздями к конкретной версии, напр. как сделано в PASETO. Давать возможность клиенту выбирать алгоритмы криптографии, и тем более "согласовывать" их динамически — плохая идея, которая создаёт намного больше проблем, чем реально решает.
Не совсем. Версия одна, по крайней мере на стороне клиента. Версия меняется только когда в предыдущем наборе протоколов нашлась уязвимость. Это делает дальнейшую поддержку этого набора (т.е. предыдущей версии) вредной. Так что вместо согласования мы получаем скорее форсированное обновление всего на новую версию. Возможно, на какой-то период сервер может сохранить поддержку старой версии если его запустить с параметром --unsecure, но в целом тут или безопасность или поддержка старых клиентов — выберите одно из двух. И для сервисов вроде VPN выбирать не безопасность а что-то другое было бы странно. В общем, количество степеней свободы при таком подходе явно меньше, и в данном случае — это к лучшему.
Конечно, согласовывать даже десяток версий проще чем 50 произвольно комбинируемых алгоритмов шифрования, обмена ключами и хеширования. Особенно, если версии строго несовместимые и строго из одно цифры: 1, 2, 3… Но, тем не менее, какое-то согласование всё-равно, надо будет встраивать.
Всё верно — пока речь об абстрактном приложении "в вакууме". А если мы говорим про конкретный wireguard, то "в теории" и "на практике" надо поменять местами. Потому что на практике конкретно wireguard продолжать пользоваться при наличии известной уязвимости в протоколе — смысла нет.
Таким образом, если он перестанет быть доступен на устаревшем андроиде в связи с уязвимостями, и там не будет возможности обновить wireguard — значит либо там можно будет переключиться с wireguard на другой VPN, либо данным устройством действительно стоит перестать пользоваться не смотря на вызванные этим неудобства (раз уж вы сослались на проблемы letsencrypt, то я в свою очередь симметрично сошлюсь на ситуацию с adobe flash).
Такой жёсткий подход к версионированию протокола применим не везде — но для приложений обеспечивающих безопасность — он вполне может быть оправдан.
Потому что на практике конкретно wireguard продолжать пользоваться при наличии известной уязвимости в протоколе — смысла нет.
Бывают уязвимости и уязвимости. Проводить серьёзное обновление инфраструктуры из-за трудноиспользуемой уязвимости — не разумно.
Андроид я привёл просто для иллюстрации того, что даже популярная и постоянно подключенная к сети платформа может иметь проблемы с обновлениями. Есть ситуации, когда обновиться намного труднее. Всякое IoT, старые дорогие маршрутизаторы специального назначения и т.п.
А жёсткий подход — это хорошо, но для этого у соответствующего комитета должны быть стальные яйца, чтобы отфутболивать всяких представителей корпораций, которые обязательно набегут со всякой корпоративной мерзостью.
Тем не менее, текущая тенденция идёт именно в эту сторону: браузеры переходят на https, активно давят на вебсайты по всему миру чтобы они начинали использовать https, усиливают контроль за выпущенными сертификатами (CT), сопротивляются использованию левых сертификатов (pinning), блокируют флеш… и даже банально рекомендуют сайтам и плагинам поддерживать совместимость с последними двумя версиями браузеров. Аналогичное происходит и в мире OS, Microsoft и Apple из всех сил пытаются принудить всех пользователей и все устройства оперативно обновляться. В мире IoT тоже есть схожие тенденции, правда пока в начальной стадии: пока что всех пугают масштабами уязвимостей и окирпичиваемых устройств, вызванных отсутствием регулярных обновлений (как со стороны производителей, которые забивают на поддержку устаревших устройств, так и со стороны юзеров, который купили-включили-забыли и сами ничего не обновляют). Появляются технологии защиты от сбоя при обновлении, вроде A/B-слотов в андроиде. В общем, всё делается для того, чтобы обеспечить регулярное обновление абсолютно всего софта на всех устройствах.
Конечно, всё это навязывается вовсе не из заботы о безопасности юзеров. Но, в качестве побочного эффекта, это заодно решает и данную проблему. Поэтому подход wireguard кажется вполне адекватным в данных условиях, может самую малость опередившим своё время, но не более того.
Как WireGuard проходит проверку анонимности на 2ip? Fingerprint есть?
Если не требуется мобильность, есть еще старый добрый SoftEther, умеющий в том числе мимикрировать под обычный HTTPS.
Интересно, я проверял переключение специально, и всё нормально:
$ ping 192.168.29.226 (это телефон, подключённый по VPN WireGuard)
PING 192.168.29.226 (192.168.29.226) 56(84) bytes of data.
64 bytes from 192.168.29.226: icmp_seq=1 ttl=64 time=1.70 ms (подключение по проводу)
64 bytes from 192.168.29.226: icmp_seq=2 ttl=64 time=1.35 ms
64 bytes from 192.168.29.226: icmp_seq=3 ttl=64 time=1.87 ms
64 bytes from 192.168.29.226: icmp_seq=6 ttl=64 time=2.88 ms (переключение на WiFi)
64 bytes from 192.168.29.226: icmp_seq=7 ttl=64 time=28.1 ms
64 bytes from 192.168.29.226: icmp_seq=8 ttl=64 time=258 ms
64 bytes from 192.168.29.226: icmp_seq=9 ttl=64 time=4.39 ms
64 bytes from 192.168.29.226: icmp_seq=10 ttl=64 time=100 ms
64 bytes from 192.168.29.226: icmp_seq=11 ttl=64 time=19.9 ms
64 bytes from 192.168.29.226: icmp_seq=12 ttl=64 time=246 ms
64 bytes from 192.168.29.226: icmp_seq=13 ttl=64 time=168 ms
64 bytes from 192.168.29.226: icmp_seq=14 ttl=64 time=3.03 ms
64 bytes from 192.168.29.226: icmp_seq=15 ttl=64 time=1.97 ms (переключение обратно на провод)
64 bytes from 192.168.29.226: icmp_seq=16 ttl=64 time=1.93 ms
64 bytes from 192.168.29.226: icmp_seq=17 ttl=64 time=1.35 ms
Переключение с проводного подключения на WiFi занимает около 2-3 секунд, а обратно происходит практически мгновенно (поэтому я думаю, что сам по себе WireGuard отрабатывает переключение очень быстро). При этом IP-адреса у самих подключений по проводу и по Wi-Fi разные.
Тест с ping -i 0.01, для более точного определения времени переключения:
с провода на Wi-Fi пропущено 190 пакетов
с Wi-Fi на провод пропущено 0 пакетов (при этом задержка также не росла)
На мобилене отрабатывало смену сети.
Я на мобиле проверял именно.
Так выглядит переключение с мобильной сети на Wi-Fi:
64 bytes from 192.168.29.226: icmp_seq=6 ttl=64 time=26.3 ms (мобильная сеть)
64 bytes from 192.168.29.226: icmp_seq=7 ttl=64 time=24.6 ms
64 bytes from 192.168.29.226: icmp_seq=8 ttl=64 time=31.7 ms
64 bytes from 192.168.29.226: icmp_seq=13 ttl=64 time=7.99 ms (Wi-Fi)
64 bytes from 192.168.29.226: icmp_seq=14 ttl=64 time=6.70 ms
64 bytes from 192.168.29.226: icmp_seq=15 ttl=64 time=339 ms
64 bytes from 192.168.29.226: icmp_seq=16 ttl=64 time=3.19 ms
64 bytes from 192.168.29.226: icmp_seq=17 ttl=64 time=6.20 ms
64 bytes from 192.168.29.226: icmp_seq=18 ttl=64 time=3.43 ms
64 bytes from 192.168.29.226: icmp_seq=19 ttl=64 time=28.1 ms
64 bytes from 192.168.29.226: icmp_seq=20 ttl=64 time=6.73 ms
64 bytes from 192.168.29.226: icmp_seq=23 ttl=64 time=110 ms (мобильная сеть)
64 bytes from 192.168.29.226: icmp_seq=24 ttl=64 time=36.7 ms
64 bytes from 192.168.29.226: icmp_seq=25 ttl=64 time=44.0 ms
задержка побольше, но все равно в пределах нескольких секунд.
Ещё один тест: в параметрах разработчика включена опция "Не отключать мобильный интернет для быстрого переключения между сетями".
С мобильной сети на Wi-Fi практически мгновенно, без пропусков с -i 0.1, обратно задержка около 1 секунды.
Значит дело точно не в типе VPN-соединения, а в реализации переключения сетей на самом устройстве.
Перечитал ещё раз, и возник вопрос. А что все таки лучше и предпочтительней выбирать?
Интересно, почему такие результаты скорости, особенно с учетом того, что Wireguard не использует AES (аппаратная реализация которого сейчас есть в каждом современном x86 или arm процессоре).
Неужели этот ChaCha20 быстрее аппаратного AES-NI?
Благодаря высокой скорости есть ещё один вариант использования Wireguard — распределённые сети.
На разных этажах здания стоят разные Wi-Fi точки и розетки проводной сети, подключённые к сети без доступа в интернет и важным корпоративным ресурсам. В этой сети открыт только доступ к портам VPN сервера на Wireguard, через который уже можно получить доступ куда надо. И не важно, через что сидит пользователь, через Wi-Fi, провод, или VPN извне, сидит ли он в офисе, в какой-то общей зоне или дома — он будет доступен по постоянному адресу. Пришёл сотрудник на работу — выдали ему ключ. Ушёл — заблокировали. По постоянным IP хорошо вести логи и настраивать права, корпоративная система может узнавать пользователей по их внутренним IP (хотя пароли пусть все равно остаются на случай, если незаблокированное устройство попадёт в руки другого пользователя).
Система работает в том случае, если в здании размещается несколько компаний, и есть общее рабочее пространство, тогда из общей сети здания открывается доступ к нескольким VPN серверам, принадлежащим каждой компании, и сотрудники каждой компании имеют доступ к своим ресурсам.
Кто попало не подключится к сети, даже узнав пароль Wi-Fi или воткнувшись в сетевую розетку.
Недостаток такого решения — большой трафик через VPN сервер (интересно, можно ли его кластеризовать, чтобы масштабировать добавлением нового узла в кластер).
Не, лучше уж по-старинке: 802.1X для прямого подключения к сети и openvpn с тем же сертификатом. Это вместо того, чтобы заморачиваться доморощенным шифрованием по ключам, которое ещё и не поддерживает никто из крупных вендоров.
Да и развертывать wireguard в более-менее крупной компании — это стрелять себе в ногу. Отсутствие пуша маршрутов и динамических IP лишает архитектуру сети гибкости. Wireguard неплох как туннель точка-точка, но как корпоративный VPN он в текущем виде не годится.
Что у Микротика есть, тем и пользуемся :( Wireguard какой-то, OpenVPN… поди ещё UDP? Вишь чего удумали
Недостаток WireGuard: нельзя понять, действительно ли установлено соединение. Сервер может лечь, доменное имя смениться, а клиент все равно считает, что соединение установлено.
Некое подобие проброски маршрутов можно получить опцией AllowedIP.
А как конкретно Вы пытались понять, установлено ли соединение? Я вот обычно это без проблем вижу, как на линухе в командной строке (вывод wg показывает как давно был последний handshake и статистику переданных байт), так и в UI андроид-клиента (там показывается статистика, и количество принятых байт 0 вполне однозначно намекает).
Это намёки, требующие анализа. Клиент GUI под Windows соединение "устанавливает" и маршрут прописывает, даже если прописать произвольный адрес сервера. И это какая-то жесть, если честно. Могу предложить, что это дополнительный уровень безопасности, не знаю
nmcli так же себя ведёт, ну а GUI в текущих сборках у NM нету (
Это просто потому что Wireguard почти полностью stateless. У него нет собственно "установленного" соединения. Как нет и авторизации. И вообще "сервера" в Wireguard тоже нет. Там все клиенты, при чем равноправные. И вполне нормальна ситуация когда один из двух peer-ов живой, а второй — нет.
Просто пришел пакет: получилось расшифровать своим приватным ключем, обработали. Нужно отправить, зашифровали публичным ключем получателя, отправили. Выше уже советовали смотреть время последнего handshake (это по факту даже не handshake а время, когда последний раз что-то приходило).
По хорошему 'красивый' GUI клиент мог бы пинговать каждый peer и какое-то уведомление показать.
Я примерно как-то так и думал. Но с точки зрения пользователя ситуация плохая.
Спорно. Для меня наоборот. Это чуть ли не единственный VPN который может быть постоянно запущен на телефоне (например, чтобы постоянно иметь доступ к ресурсам домашнего NAS) и при этом он вообще не будет садить батарею.
а NAT сессию кто держать будет? или у вас IPv6?
Вообще конкретно мне не нужна связь в обратную сторону (в смысле когда какой-то хост из дома пытается первым достучаться к телефону). В таком случае про NAT можно не думать вообще. Если не включать keepalive, то Wireguard не шлет вообще ничего. Соответственно да, NAT сессия протухнет через какое-то время. В следующий раз от телефона просто прийдет пакет с другим UDP src port. На стороне получателя просто обновится адрес: порт с какого последний раз приходило что-то от телефона и всё.
Как раз с точки зрения пользователя wireguard проще и удобнее в установке/настройке, лучше и быстрее работает — и это сложно назвать плохой ситуацией, даже если где-то UX и не идеален.
Я, в принципе, согласен, что отлаживать wireguard не так удобно, как OpenVPN. Но идея в том, что там особо нечего отлаживать, если ключи и IP корректные, и его трафик по дороге никто не режет — то wireguard обычно просто работает. Сравнить пару ключей и один IP — не так сложно. Если с ними всё ок — дальше надо смотреть трафик на предмет а приходят ли вообще ответные пакеты на клиенте и отправляются ли они на сервере.
sudo emergeНе у всех же Gentoo — хоть бы упомянули тогда об этой мелочи
А ещё не у всех убунта — но кого это останавливало от публикации примеров команд запускающих apt без уточнения что это не везде сработает? У нас тут опять кто-то "равнее" других, и что дозволено убунтоводам не дозволено гентушникам?
Вы вообще читали ту часть моего комментария, что после тире?
P.S. Не стоит брать дурные примеры в качестве примеров для подражания
P.P.S. Сам пользователь Gentoo
Я всё внимательно читал. И я согласен насчёт "хорошим тоном" и "дурные примеры". Но. Пока так почти никто не делает в случае apt (а это, к сожалению, именно так), то формально "хороший тон" начинает звучать как "извините, у нас тут команда работающая только в маргинальном дистре, у вас она почти наверняка не сработает, и вообще не понимаю зачем я её тут вообще пишу, и ещё раз извините пожалуйста".
По-хорошему, если статья не на сайте/форуме конкретного дистра, и её будет читать широкая аудитория, то в ней нужно приводить примеры дистро-специфичных команд хотя бы для 2-3 популярных дистров. Заметьте, не любимого автором дистра. И не того, который у него сейчас установлен. А тех, которые у большинства читателей. Плюс к этому уже можно добавить любое количество альтернатив для менее популярных дистров, если есть такое желание. Вот это — хороший тон. Но это требует дополнительных усилий, которые мало кто делает.
А то, что предложили Вы — бессмысленно. Пользователи Gentoo команду опознают и без уточнения, что она для Gentoo, а у остальных она не сработает, и наличие уточнения что она работает но в каком-то неизвестном им дистре никому из них не поможет. Иными словами, даже сделав уточнение насчёт Gentoo автор всё-равно полагает, что читатели использующие другие дистрибутивы в состоянии самостоятельно выявить аналогичную команду работающую для них — но упоминание Gentoo этому никак не способствует, потому что всё-равно никто не будет отдельно гуглить "что делает emerge в Gentoo", вместо этого или догадаются из контекста или забьют и пройдут мимо.
Стоит отметить ещё то, что wireguard-modules нужен для старых ядер. В новых (начиная с 5.6) модуль wireguard уже встроен в ядро, и его надо просто включить в конфиге CONFIG_WIREGUARD=y.
Ни слова про NAT, ни слова про работу из анальноогороженных местечек через HTTP-прокси (OpenVPN этоумеет)…
openvpn на порядок фичастее, кому нужна скорость уже 20 лет юзают IPSEC, разница с WG непринципиальная.
А как форсят WG изо всех щелей — это уже и подозрительно.
Ещё и ни в одном путнем серверном дистрибе его нет, dkms спасибо не надо.
Итого: подождите ещё 5-10 лет, там посмотрим…
OVPN умеет пушить маршруты, пушить сетевые настройки с сервера клиентам. Умеет работать через proxy. В этом случае выбор падает на ipsec или ovpn. В ovpn 2.5 добавили алгоритмы, к-ые пользует и WG.
ЗЫ. Ovpn нужно докручивать под свои нужды docs.netgate.com/pfsense/en/latest/vpn/performance.html
Используйте Wireguard.
все, кому нужно надежное и проверенное временем решение для VPN;
UDP блокируется во многих аэропортах и прочих публичных местах. Так что если надо действительно надёжное решения, то нужна поддержка TCP на порту 443.
Что лучше выбрать: Wireguard или OpenVPN? Любимый VPN Линуса Торвальдса