Комментарии 124

Ну тут видите ребята — все очень субъективно и каждому своё. Но статья огонь! Спасибо! Читал с интересом

Интересно было бы посмотреть разницу не на мощном ПК, а на слабом RPi или Openwrt роутере
Но моем роутере на стоковой Keenetic OS Wireguard быстрее минимум в 3 раза.
Бюджетный Keenetic Air.
На 100-мегабитном канале результаты тестирования скорости следующие (speedtest, Wi-Fi, download/upload):
— без vpn: 91/92;
— wg: 35/29;
— ovpn: 8/7.
При этом, если подключиться к ovpn с десктопа, то скорость выдает 84/87.
Привел результаты первых же измерений, средние показатели не получал, но они близки к приведенным числам.
Как раз в декабре перешёл с OpenVPN на WireGuard. Примерные замеры скорости дают такие результаты:
TP-Link Archer C7 v5, OpenWRT-SFE.
OpenVPN 10 Mbit/s
WireGuard 80 Mbit/s

Оба решения упираются в CPU маршрутизатора. Отключение шифрования в OpenVPN (насколько я разобрался как это сделать) поднимало скорость примерно до 15 Mbit/s.

Для заворачивания по списку РКН — должно полностью хватить. Если есть желания завернуть весь трафик в туннель, то скорее всего имеет смысл выбрать железку помощнее.

Для заворачивания хватит, но вот крутить по ок 2k видео уже маловато Будет. Насчёт маршрутизатора интересный факт. Видимо стандартных от провайдера уже не хватает

На моём OpenVPN тоже упирается в 10Мб/с. Жаль Wireguard нет в стоковой прошивке для теста.

В чем проблема поставить? — opkg install wireguard. Он даже не тянет за собой модулей ядра (что странно, или нет?).
У меня стоковая прошивка, руки не доходили попробовать перепрошить. Да и вроде работает, зачем трогать :)

ничего странного
или там уже свежее ядро и wg "вшит" в него
или там ядро не очень свежее но мейнтейнер всё равно запихнул wg в ядро
или там юзерспейсный wg как до сих пор в openbsd емнип

OpenBSD в июне перешли на ядерный wg. За ним NetBSD. По-моему, в декабре и FreeBSD.
К слову сказать, в OPNSense (а это есть форк FreeBSD) есть wg. Так вот, он быстр и прекрасен даже в виде userspace'ного плагина.

На моем openwrt-роутере было недостаточно ресурсов даже для запуска openvpn. wireguard работал чуть ли не со скоростью аплинка.

Тогда нужно настроить в соединении OpenVPN шифрование ChaCha20. Его поддержка как раз появилась в 2.5.0 для устройств без аппаратного AES как в Intel Core i… Я делал на двух серверах на 10Г интерфейсах тесты сравнения. OpenVPN вытянул 1.8Гбит. WireGuard 4Гбит. Меня вполне устраивает мощность OpenVPN.

Между двумя роутерами на mt7621 на OpenWRT 19.07.5 Wireguard дает 180-200mpbs (300mbps аплинк на обоих). OpenVPN оставался в районе 30mbps.
Интересно посмотреть вновь, когда в mt7621 начнут поддерживать аппаратную крипту на EIP-93. Кроме того, там в этом движке есть примитивы для IPSec, поэтому если будет не только ускорение крипты, но и аппаратная обработка пакетов IPSec, последний может оказаться самым быстрым решением.

К сожалению, Wireguard не прячет пакеты и легко блокируется. А так — он в самом деле быстрее. Документация для корпоративного использования (если ничего не изменилось за 2 прошедших года) бедновата. Клиент под IOS появился уже тогда, хоть и был кривоват. Это лишний показатель того, что продвигают его очень активно по всем платформам.
Прятать пакеты — это отдельный уровень. Можно поднять туннель который прячет пакеты, а внутри пустить wireguard. Кажется концептуально более правильно такие решения разделять.
Но ведь тогда мы делаем одну работу дважды. Сначала шифруем payload чтобы его не подсмотрели, а потом еще шифруем пакеты (payload + заголовок) чтобы никто не понял что это за пакеты.
Посоветуйте, кстати, рабочий UDP-туннель, чтобы работал вместе с wireguard в том числе на винде, на андроиде и на роутерах из коробки.
К сожалению, Wireguard не прячет пакеты и легко блокируется.


Он решает вопросы шифрования. Прятать трафик — это о другом.
И хотя шифровать трафик и прятать трафик в некоторых случаях идет рядом — но всё же вторая задача не является целью Wireguard на сегодня, он не для этого.

Не нашел в доках на офсайте как исключить локальные подсети из vpn туннеля на клиенте. Можете подсказать?
Да, там по умолчанию AllowedIPs = 0.0.0.0/0, т.е. чтобы исключить локалку надо разрешить все другие сети, кроме своей локалки? Логика странная, не понятно что конкретно сюда прописывать.
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1
Примерно как для локалхоста? Ну да границы задавать придётся…
Из этого видно, что при настройке Wireguard IP адрес, либо имя узла задаются в явном виде

Один из пиров может не указывать в своём конфиге Endpoint другого пира — тогда он будет назначен автоматически при его подключении (хотя залогировать подключившйся айпишник всё равно никто не запрещает)

Вот вся проблема в логах и есть. Взял себе сервак в google cloud, поднял там Wireguard, подключился с телефона и в логах обнаружил свой обычный IP. Это же ни в какие ворота. Свернул ВМ и забыл о Wireguard

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

Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя.
И адрес клиента в настройках сервера не задаётся, более того, он может меняться во время работы без разрыва соединения. Там задаётся адрес внутри VPN, но он вообще может быть внутренним и никак не выдаёт местоположение пользователя, а также публичный ключ (которого недостаточно, чтобы подключиться от имени клиента, в конфиге которого лежит приватный ключ).
Преимущество OpenVPN в том, что он поддерживает разные способы аутентификации и динамическую выдачу IP-адресов. С Wireguard вам понадобится какой-то свой сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера — а в OpenVPN это доступно из коробки. Поменялся IP на стороне пользователя — ему надо поменять конфиг, а OpenVPN просто выдаст новый.

сервис, который реализует вход пользователя в систему (например, вводом логина и пароля в веб-форму, доступную без VPN по HTTPS), генерит для него конфиг, прописывает туда IP и ключи, добавляет пользователя в конфиг сервера

github.com/StreisandEffect/streisand/blob/master/README-ru.md

Это антицензурный VPN. А как насчёт применения VPN на предприятиях для удалённого доступа? админ же замучается каждому выдавать ключи, адреса и следить за всем этим.

да не, норм
сначала хотели наваять скрипт для того чтобы не лазить руками, но опыт показал что и руками это делается легко и быстро

Интересно, что у меня оказался Wireguard быстрее даже на смартфоне, где он работает в пространстве пользователя

Версию ядра проверьте. Может уже и в ядре.

Версия ядра: 3.18.140
Версия Android: 10
Вряд ли. Специальный модуль для wireguard если и есть на android, то только в кастомных прошивках.

А зачем вообще прописывать 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.

Забавно, что винда и макось получили гуй версию, а на линуксе её так и нет.
Если тебе впн нужно включить разово, чтоб зайти на рутрекер, это немножко подбешивает.
В макоси я правда написал скриптик для Автоматора, чтобы ВГ тогглился по сочетанию клавиш. Это когда еще гуёв не было, с тех пор им и пользуюсь

Пес его знает, но в KDE5 оно есть в настройках сетевых соединений.

Для таких целей проще HTTP прокси на SSH поднять и использовать расширение по типу switchyomega у хрома. Все прозрачно и просто.
HTTP вполне достаточно, т.к. в нём есть метод Connect, который можно использовать для последующего проброса ssh-туннеля с нормальным SOCKS.

Как то пришлось использовать это, для обхода корпоративного прокси (лет 7 назад, там был Forefront TMG).

Впрочем кажется дискуссия здесь была про другое, извините.
Вопрос был о проксировании средствами ssh клиента. Я было подумал, что отстал от жизни, и в нем http-прокси завелся. А socks5-прокси в нем сто лет имеется:
ssh -D <номер_порта>

Вроде бы в putty тоже можно такой прокси накликать, но я в путти не силен.
как уже написали, для такой задачи лучше подходит прокси, впн тут оверхед.
можно взять например плагин FoxyProxy — он по шаблону урла может использоваться прокси для конкретной страницы
Результату iperf3 я бы не доверял. Сыровата утилитка. По своему опыту использования при нагрузке канала UDP-пакетами, то iperf3 показывал 90% потерь там, где iperf2 показывал — 0%.
Как все подробно расписано. Остаётся сделать выбор. Но зачастую даже самый быстрый сервер впн начинает тормозить, кажется парой что лучше и без него
Ну да ну да, «честным людям же нечего скрывать», зачем же заставлять товарища майора лишний раз потрудиться…
В отличие от OpenVPN, Wireguard не использует сертификаты X.509 и лишен сопутствующих проблем. Вместо этого Wireguard использует асимметричное шифрование с открытым и закрытым ключом.

Во-первых, сертификат Х.509, это и есть ассиметричное шифрование с закрытым и открытым ключом. Сертификат хранит открытый ключ. Во-вторых, отсутствие разнообразия способов аутентификации — это минус, а не плюс. Да, если настраивать один туннель от дома до VPS, можно и руками ключи прописать. Но для промышленных решений нужны какие-то штуки посерьёзней.
Wireguard исповедует минималистский и безапелляционный подход к шифрованию, преднамеренно исключив гибкость и альтернативу выбора протоколов

Через 10 лет поли/чача устареют и придётся вводить новый алгоритмы, а с ними и гибкость и альтернативу выбора.
а с ними и гибкость и альтернативу выбора.

Не обязательно. Достаточно передавать номер версии протокола, а используемые алгоритмы прибить гвоздями к конкретной версии, напр. как сделано в PASETO. Давать возможность клиенту выбирать алгоритмы криптографии, и тем более "согласовывать" их динамически — плохая идея, которая создаёт намного больше проблем, чем реально решает.

Тогда придётся динамически согласовывать версии. Те же яйца, только в профиль.

Не совсем. Версия одна, по крайней мере на стороне клиента. Версия меняется только когда в предыдущем наборе протоколов нашлась уязвимость. Это делает дальнейшую поддержку этого набора (т.е. предыдущей версии) вредной. Так что вместо согласования мы получаем скорее форсированное обновление всего на новую версию. Возможно, на какой-то период сервер может сохранить поддержку старой версии если его запустить с параметром --unsecure, но в целом тут или безопасность или поддержка старых клиентов — выберите одно из двух. И для сервисов вроде VPN выбирать не безопасность а что-то другое было бы странно. В общем, количество степеней свободы при таком подходе явно меньше, и в данном случае — это к лучшему.

Это всё хорошо и красиво в теории. На практике же, треть android-устройств чуть было не остались без шифрованного интернета в этом году, потому что не имеют возможности обновить корневой сертификат. Это не протокол, который обновляется вместе с ядром линукса, это просто корневой сертификат — base64-закодированный блоб килобайта на 3. И это на самой популярной в мире потребительской платформе.
Конечно, согласовывать даже десяток версий проще чем 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 кажется вполне адекватным в данных условиях, может самую малость опередившим своё время, но не более того.

OpenVPN использует tun интерфейс и работает в юзерспейсе — и этим все сказано.


С другой стороны, WireGuard достаточно ограничен в плане функциональности и для чего-то сильно серьезного не годится… но при этом для его использования не нужно с сертификатами возиться, достаточно пары ключей.

OpenVPN кроме tun может использовать ещё и tap. Wireguard такого не умеет.

Как WireGuard проходит проверку анонимности на 2ip? Fingerprint есть?

Лично для меня киллер-фичей OpenVPN является возможность вбрасывания маршрутов для клиента (причём для каждого отдельно, или общих, по желанию). Для WG это, очевидно, придётся делать скриптами, никакой гибкости. Ну или какую-то динамическую маршрутизацию поверх городить… Такое себе…
Согласен. Одно дело, когда разово настраиваешь связь между серверами или к какой-то удалённой площадке. А когда сотня пользователей, к которым надо подключаться чтобы маршруты прописать, или давать инструкцию со скриптами, и никто не читает эти инструкции, или не хочет. После этого у OpenVPN не так много недостатков.
На мобиле на родном клиенте Wireguard не взлетел из-за больших таймаутов при переключении между точками Wifi и/или сотовой сетью, тогда как у ShadowSocks (клиент Outcast вроде) таких проблем обнаружено не было. Подозреваю, что дело в необходимости хендшейка, который SS просто не нужен.

Если не требуется мобильность, есть еще старый добрый 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-соединения, а в реализации переключения сетей на самом устройстве.

Интересно, а для чего сравнивать с OpenVPN, всё-таки продукт немного иного класса, клиентского уровня выполнения. Можно например сравнить с IKE2\IPSec на Strong swan к примеру. У меня как раз на сервере подняты оба, и Swan и OpenVPN. Сравниваю. Да, Swan быстрее, но OpenVPN за счёт поднятия отдельного интерфейса tun0 на сервере и отдельного интерфейса в Микротике проще настраивается, и по моим наблюдениям работает надёжнее. А так, оба решения одну задачу решают одинаково хорошо.

Перечитал ещё раз, и возник вопрос. А что все таки лучше и предпочтительней выбирать?

Перечитал ещё раз, и возник вопрос. А что все таки лучше и предпочтительней выбирать?

Смотря зачем.
Выводы — в конце статьи.
Смотря для каких задач и на каком оборудовании будет работать. Например поддержка WireGuard для Mikrotik есть только в development прошивках. А OpenVPN или IPSec есть давно, и по ней куча информации. Да и то, когда я настраивал маршрутизацию пакетов на через IPSec я внятной русской инструкции не нашел, пришлось порыться в источниках. Так что эта технология любопытная, но пока совсем еще новая.

Ага… При этом OpenVPN в Mikrotik-е по UDP умеет работать тоже только в development прошивках… А по TCP им пользоваться смысла мало.

Да, все так. А еще там компрессия не поддерживается. Ну, на микротике конечно свет клином не сошелся, но я не знаю, поддерживают ли WireGuard другие производители. Да и потом, слишком пока много ограничений у него как протокола, так и сервера и клиента. Вот, кто-то пишет, что нет поддержки исключения внутренних подсетей, а это важно. Ну и так далее. В общем любопытно, но пока рано делать вывод об его преимуществах. Если уж так хочется быстрый VPN — то IKE2/IPSec вполне подходит, есть почти все преимущества WireGuard без его недостатков. Но со своими, конечно, недостатками. ;)
На самом деле, здесь довольно сложный выбор. Кому как нравится, как говорится)
А ещё кому-то мелочь (мне нет), а приятно: клиент OpenVPN под Windows отвратителен с точки зрения доступности (accessibility) для пользователей программ экранного доступа (то есть не совсем полный кошмар, справиться можно, если ты более или менее опытный пользователь, но удовольствия ноль), а у WireGuard клиент очень простой и доступный.
Ну это хорошо, что для блондинок. Именно с точки зрения легкости использования клинтов. Вот и интересно мне: насколько он хуже по скорости и безопасности…

Интересно, почему такие результаты скорости, особенно с учетом того, что 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? Вишь чего удумали

в 7 версии появилась поддержка wirenguard, а openVPN вроде бы там давно уже был (хотя он был не очень, да).
еще SoftEther забыли для сравнения добавить, тоже годное решение между прочим для разных нужд
Browsec — я думаю самый лучший VPN, другие медленно загружаются и плохо работают.

Недостаток WireGuard: нельзя понять, действительно ли установлено соединение. Сервер может лечь, доменное имя смениться, а клиент все равно считает, что соединение установлено.


Некое подобие проброски маршрутов можно получить опцией AllowedIP.

А как конкретно Вы пытались понять, установлено ли соединение? Я вот обычно это без проблем вижу, как на линухе в командной строке (вывод wg показывает как давно был последний handshake и статистику переданных байт), так и в UI андроид-клиента (там показывается статистика, и количество принятых байт 0 вполне однозначно намекает).

Это намёки, требующие анализа. Клиент GUI под Windows соединение "устанавливает" и маршрут прописывает, даже если прописать произвольный адрес сервера. И это какая-то жесть, если честно. Могу предложить, что это дополнительный уровень безопасности, не знаю


nmcli так же себя ведёт, ну а GUI в текущих сборках у NM нету (

Это просто потому что Wireguard почти полностью stateless. У него нет собственно "установленного" соединения. Как нет и авторизации. И вообще "сервера" в Wireguard тоже нет. Там все клиенты, при чем равноправные. И вполне нормальна ситуация когда один из двух peer-ов живой, а второй — нет.


Просто пришел пакет: получилось расшифровать своим приватным ключем, обработали. Нужно отправить, зашифровали публичным ключем получателя, отправили. Выше уже советовали смотреть время последнего handshake (это по факту даже не handshake а время, когда последний раз что-то приходило).


По хорошему 'красивый' GUI клиент мог бы пинговать каждый peer и какое-то уведомление показать.

Я примерно как-то так и думал. Но с точки зрения пользователя ситуация плохая.

Спорно. Для меня наоборот. Это чуть ли не единственный VPN который может быть постоянно запущен на телефоне (например, чтобы постоянно иметь доступ к ресурсам домашнего NAS) и при этом он вообще не будет садить батарею.

Вообще конкретно мне не нужна связь в обратную сторону (в смысле когда какой-то хост из дома пытается первым достучаться к телефону). В таком случае про NAT можно не думать вообще. Если не включать keepalive, то Wireguard не шлет вообще ничего. Соответственно да, NAT сессия протухнет через какое-то время. В следующий раз от телефона просто прийдет пакет с другим UDP src port. На стороне получателя просто обновится адрес: порт с какого последний раз приходило что-то от телефона и всё.

Как раз с точки зрения пользователя wireguard проще и удобнее в установке/настройке, лучше и быстрее работает — и это сложно назвать плохой ситуацией, даже если где-то UX и не идеален.


Я, в принципе, согласен, что отлаживать wireguard не так удобно, как OpenVPN. Но идея в том, что там особо нечего отлаживать, если ключи и IP корректные, и его трафик по дороге никто не режет — то wireguard обычно просто работает. Сравнить пару ключей и один IP — не так сложно. Если с ними всё ок — дальше надо смотреть трафик на предмет а приходят ли вообще ответные пакеты на клиенте и отправляются ли они на сервере.

В посте ни слова о том, что Wireguard умеет работать в режиме MESH. Не припомню подобной фичи у OpenVPN.
sudo emerge
Не у всех же Gentoo — хоть бы упомянули тогда об этой мелочи

А ещё не у всех убунта — но кого это останавливало от публикации примеров команд запускающих apt без уточнения что это не везде сработает? У нас тут опять кто-то "равнее" других, и что дозволено убунтоводам не дозволено гентушникам?

Я и не говорил, что не надо давать дистроспецифичных команд, а имел в виду, что было бы хорошим тоном упомянуть, что данная команда специфична для Gentoo (слово Gentoo вообще отсутствует в тексте статьи).
Вы вообще читали ту часть моего комментария, что после тире?

P.S. Не стоит брать дурные примеры в качестве примеров для подражания

P.P.S. Сам пользователь Gentoo

Я всё внимательно читал. И я согласен насчёт "хорошим тоном" и "дурные примеры". Но. Пока так почти никто не делает в случае apt (а это, к сожалению, именно так), то формально "хороший тон" начинает звучать как "извините, у нас тут команда работающая только в маргинальном дистре, у вас она почти наверняка не сработает, и вообще не понимаю зачем я её тут вообще пишу, и ещё раз извините пожалуйста".


По-хорошему, если статья не на сайте/форуме конкретного дистра, и её будет читать широкая аудитория, то в ней нужно приводить примеры дистро-специфичных команд хотя бы для 2-3 популярных дистров. Заметьте, не любимого автором дистра. И не того, который у него сейчас установлен. А тех, которые у большинства читателей. Плюс к этому уже можно добавить любое количество альтернатив для менее популярных дистров, если есть такое желание. Вот это — хороший тон. Но это требует дополнительных усилий, которые мало кто делает.


А то, что предложили Вы — бессмысленно. Пользователи Gentoo команду опознают и без уточнения, что она для Gentoo, а у остальных она не сработает, и наличие уточнения что она работает но в каком-то неизвестном им дистре никому из них не поможет. Иными словами, даже сделав уточнение насчёт Gentoo автор всё-равно полагает, что читатели использующие другие дистрибутивы в состоянии самостоятельно выявить аналогичную команду работающую для них — но упоминание Gentoo этому никак не способствует, потому что всё-равно никто не будет отдельно гуглить "что делает emerge в Gentoo", вместо этого или догадаются из контекста или забьют и пройдут мимо.

Но это требует дополнительных усилий, которые мало кто делает.
Усилий, затраченных на этот комментарий, с лихвой бы хватило

Стоит отметить ещё то, что wireguard-modules нужен для старых ядер. В новых (начиная с 5.6) модуль wireguard уже встроен в ядро, и его надо просто включить в конфиге CONFIG_WIREGUARD=y.

Убогая статья как и сам wireguard…

Ни слова про NAT, ни слова про работу из анальноогороженных местечек через HTTP-прокси (OpenVPN этоумеет)…

openvpn на порядок фичастее, кому нужна скорость уже 20 лет юзают IPSEC, разница с WG непринципиальная.

А как форсят WG изо всех щелей — это уже и подозрительно.

Ещё и ни в одном путнем серверном дистрибе его нет, dkms спасибо не надо.

Итого: подождите ещё 5-10 лет, там посмотрим…
WG — быстр, он в ядре, умеет на кофеварках.
OVPN умеет пушить маршруты, пушить сетевые настройки с сервера клиентам. Умеет работать через proxy. В этом случае выбор падает на ipsec или ovpn. В ovpn 2.5 добавили алгоритмы, к-ые пользует и WG.

ЗЫ. Ovpn нужно докручивать под свои нужды docs.netgate.com/pfsense/en/latest/vpn/performance.html
Если память не изменяет, разработчики OpenVPN уже работают над соответствующим модулем ядра.
Ребята, помогите пожалуйста с установкой WG, можете скинуть ссылку где более понятно показано как WG устанавливать?
Оно с недавних под в openbsd тоже в ядре стало жить, скорость естественно ниже, чем просто без шифрования, но просадки не чувствую, по крайней мере 500мбит канал оно в состоянии забить.
А ОС сервера на скорость влияет? Я как то WG пытался установить, и после изначальные 50 мБ с VPN стали 0.5 мБ, и пинг в 6 раз увеличился.
Разницы с линуксом особо не вижу, но я все сетевые дела предпочитаю на FreeBSD/OpenBSD/Mikrotik делать.
Можно узнать почему? BSD надёжнее и конфиденциальнее? А про последний можно подробнее?
Последний потому, что Juniper/Cisco дорого, а Mikrotik банально лучше чем «тазик с линуксом» местами выходит.
А первый потому, что начинал я с FreeBSD 4.x и мне она удобнее в сетевой части, хотя сейчас и сливает местами линуксу.
Используйте Wireguard.

все, кому нужно надежное и проверенное временем решение для VPN;

UDP блокируется во многих аэропортах и прочих публичных местах. Так что если надо действительно надёжное решения, то нужна поддержка TCP на порту 443.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации

Блог на Хабре