LINUX.ORG.RU
ФорумTalks

В OpenBSD заслали патч для поддержки Wireguard

 , , ,


0

4

В рассылку OpenBSD Tech прислали патч, реализующий поддержку Wireguard прямо в ядре. В этот раз разрабы умудрились уложиться в смешные ~3.5k строк. Ждем баттхерта от Тео и возможного включения в 6.8!

P.S. @Iron_Bug, у тебя отличный шанс показать свои скиллы на ревью.

не нужно, OpenVPN хватит всем

Harald ★★★★★ ()

А вот эти все новомодные хипсторские ChaChaPoly, они разве одобрены NSA для коммерческого применения?

Harald ★★★★★ ()
Ответ на: комментарий от kirk_johnson

я правильно понял, что на wg можно построить full mesh vpn (и выкинуть multipoint gre + nhrp + ipsec), но пока есть только основа в виде самого wg на уровне ядра, а всякие ништяки для динамики надо пилить вручную?

goodwin ★★ ()
Ответ на: комментарий от goodwin

Ну по сути WG это криптованный GRE. Если у тебя внутреняя (внутри VPN) сеть может в IPv6, ты можешь сделать динамику вот уже прям щас.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 2)
Ответ на: комментарий от kirk_johnson

под динамикой я имел ввиду некий процесс, по которому вновь присоединённый к сети пир (настроенный на присоединение только к «центральному серверу») сам узнает от сервера о существовании других клиентов.
то есть, в идеале заменить циску сервачками под OpenBSD :) с ospfd и wg, чтобы свежеподнятый сервачок цеплялся к центральному «хабу», подтягивал инфу от него об имеющихся префиксах (подсетях) и next-hop'ах к этим префиксам (внешний IP клиента + IP wg- интерфейса).
это реально будет смерть циски в области построения больших распределённых full mesh vp-сетей over Internet, во всяком случае для меня).

goodwin ★★ ()
Ответ на: комментарий от goodwin

под динамикой я имел ввиду некий процесс, по которому вновь присоединённый к сети пир (настроенный на присоединение только к «центральному серверу») сам узнает от сервера о существовании других клиентов. то есть, в идеале заменить циску сервачками под OpenBSD :) с ospfd и wg, чтобы свежеподнятый сервачок цеплялся к центральному «хабу», подтягивал инфу от него об имеющихся префиксах (подсетях) и next-hop’ах к этим префиксам (внешний IP клиента + IP wg- интерфейса).

Я сразу скажу, что я не настоящий сварщик, но DHCPv6 умеет next-hop в качестве опции. Если отдать это значение достаточно, чтобы все заработало, то как бы вот и оно.

Основная проблема, которую я вижу, это то, что WG требует заранее расшарить между клиентами пары публичных ключей. В принципе, если на центральном сервере хранить yaml файлик вида:

nodes:
   node1: { address: ..., public_key: ... },
   node2: { address: ..., public_key: ... }

И при коннекте к «центральному серверу» условная node3 подхватывает эти значения, поднимает интерфейсы, добавляет себя в этот лист и другие ноды каким-то образом это узнают (HTTP GET с опцией «не отдавай если не протухло?») и добавляют новый хост… То вот и оно.

Хотя, в идеале конечно пуш семантику. node3 цепляется, регистрируется, остальные получают push с апдейтами её ключей.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

В принципе, если на центральном сервере хранить yaml файлик вида:

Почему этому серверу и файлику должны доверять клиенты?

Harald ★★★★★ ()
Ответ на: комментарий от kirk_johnson

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

А теперь барабанная дробь - циска использует psk для адреса 0.0.0.0/0 (т.е. всякий, кто знает psk - может подключиться).
Та ещё дыра, но любой альтернативный вариант убивает простоту создания full mesh сети с шифрованием.
А WG позволяет использовать один public key для нескольких клиентов?

goodwin ★★ ()
Ответ на: комментарий от Harald

Почему этому серверу и файлику должны доверять клиенты?

Потому что в данном кейсе и сервер и файлик и клиенты являются членами одного административного домена.

goodwin ★★ ()
Ответ на: комментарий от goodwin

это как-то мешает злоумышленникам подменять файлики с ключами?

Harald ★★★★★ ()
Ответ на: комментарий от Harald

Потому что файлик подписан, например. А добавление в него через HTTP и требует подтверждения от админа.

kirk_johnson ★☆ ()
Ответ на: комментарий от Harald

это как-то мешает злоумышленникам подменять файлики с ключами?

При чём здесь безопасность?
В случае с остальными средствами для vpn риски все те же самые абсолютно.

Чем интересно WG так это тем, что, в отличие от IKE/IKE2 + ESP|AH, тут запахло ДИНАМИЧЕСКИМ построением туннелей.
Всё, что построено на IKE/IKE2 + ESP|AH, это ТОЛЬКО ручное соединение Точка-Точка.
Всё что сейчас есть на рынке, это циска с DMVPN (mgre обмазанный костылями nhrp плюс ipsec), и немного других вендоров, пытаюшихся конкурировать (fortigate, checkpoint вроде).
НО всё это во-первых vendor locked, во-вторых глюкодром, в-третьих конских денег стоит.
Мне, как сетевику, WG очень интересен с этой перспективы (динамические туннели).

goodwin ★★ ()
Ответ на: комментарий от kirk_johnson

Потому что файлик подписан, например.

А ключ, подписывающий этот файлик, на все компы личным визитом скопирован? Иначе в чём разница

Harald ★★★★★ ()
Ответ на: комментарий от Harald

А ключ, подписывающий этот файлик, на все компы личным визитом скопирован? Иначе в чём разница

На компах проверющий же. Подписывающий только на центральном сервере. Забудь про файлик, замени его понятием «база данных».

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 2)
Ответ на: комментарий от goodwin

Понимаешь, какая шляпа, тут по сути те же приколы, что и в IPsec. Просто вокруг WG чуть проще скриптовать.

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

тут по сути те же приколы, что и в IPsec

Ну... не совсем. Как минимум сетевой интерфейс один для нескольких пиров.
А если то, что я хочу, вместо скриптования дописать на Сишечке как доп.фичу к WG, то получится совсем красота.
Время только было б..
По сути, конечно, да, многое похоже, но сильно удобнее изначальный дизайн.

goodwin ★★ ()
Ответ на: комментарий от goodwin

Короче, я примерно придумал, а ты мне сейчас расскажешь, насколько то, что я придумал, рабочая схема.

Изначально нет ничего кроме этого самого центрального сервера. У нас есть первая нода, которую нужно добавить. Админ, вводящий эти ноды, регает первую:

node1$ mesh register mesh-master.example.com
Enter super mega secret password: ...

После чего нода радостно попадает в mesh сеть. Что это значит? У неё есть запущенный демон, назовем его meshd, который регается на центральном сервере. Регается от вот как: генерит себе wg private/public, пушит свой IP и public на mesh-master.example.com, забирает с mesh-master публичный ключ для проверки пушей (ну или админ вводит его заранее) и уходит в спячку.

Когда добавляется вторая нода, присходит все то же самое, только mesh-master присылает node1 оповещение: у нас новый чувак, node2, вот его public, подсети и IP. node1 создает к node2 новый туннель и снова уходит в спячку.

Насколько это все ок?

Разумеется, разных mesh сетей может быть просто дохрена.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 5)
Ответ на: комментарий от kirk_johnson

Да, годно.
А поверх этого уже можно по ospf префиксы раздавать (предположим что все эти сервачки mesh-master, node1, node2, ... - это маршрутизаторы).
Ну и совсем хорошо, если поднимать туннели тогда, когда нужно слать трафик (чтобы всем нодам не держать в памяти кучу SA (или как это в WG называется)).
Это можно реализовать на основе icmp-редиректа с mesh-mastera в сторону ноды.
Надеюсь найду время посмотреть этот патч и как это работает в текущей реализации.

goodwin ★★ ()
Ответ на: комментарий от goodwin

Ну WG stateless, так что никто не мешает добавлять пира только тогда, когда он нужен. Другое дело, что я хз, не экономия ли это на спичках.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

хз, не экономия ли это на спичках.

Когда есть 90+ филиалов, и нужно собрать это в full mesh сеть.. и оказывается что сделать это автоматизированно можно только за кучу бабла.. (циско-фигиско или ещё что-то)
OpenBSD и WG будет отличной альтернативой. Учитывая что железо тут не сильно производительное нужно (ибо скорости каналов не более 30-50 мегабит в 80% точек).

goodwin ★★ ()
Ответ на: комментарий от goodwin

Ну так пока они в памяти висят, они только RAM едят. Не думаю, что сильно.

kirk_johnson ★☆ ()
Ответ на: комментарий от kirk_johnson

А, ты про это. Я думал имеешь ввиду экономию от всей идеи full mesh'а)
В целом на первое время можно и пренебречь тем, что туннели постоянно подняты.

goodwin ★★ ()
Ответ на: комментарий от goodwin

Я просто хз, когда я упаковывал все BGP маршруты в дерево (типа, вообще все), получалось шото в районе 50 мегабайт. И это с дополнительными данными.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 2)
Ответ на: комментарий от kirk_johnson

Я просто хз, когда я упаковывал все BGP маршруты в дерево (типа, вообще все), получалось шото в районе 50 мегабайт.

Маршруты всего интернета?

Harald ★★★★★ ()
Ответ на: комментарий от Iron_Bug

Ох уж эти говнокодеры, им уже для впна отдельные платы подавай...

stasolog ()
Ответ на: комментарий от stasolog

Ох уж эти говнокодеры, им уже для впна отдельные платы подавай...

Есть иное решение для 100G+, например?

Meyer ★★★★ ()
Ответ на: комментарий от Meyer

А в чем проблема со 100G? ChaCha20 360 GB/s может на каких-то специальных процах.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

может на каких-то специальных процах

Попадает под категорию «специальные железки».

Meyer ★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)