Дэйвид Миллер (David S. Miller), отвечающий за сетевую подсистему ядра Linux, принял в состав ветки net-next патчи с реализацией VPN-интерфейса от проекта WireGuard. В начале следующего года изменения, накапливаемые в ветке net-next, лягут в основу выпуска ядра Linux 5.6...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51997
Алилуйя! Хотя dkms и так прекрасно собирает модуль, но если будет в ядре из коробки это приятно
Чей-то там сторонний модуль - это одно. А ядерный модуль - другое. Если посторонний модуль ядро уронит - никто как бы не виноват. А если встроенный в ядро - Торвальдс костьми ляжет чтобы такого не произошло.
Нафига? Разработчики ядра мне всё больше напоминают алкашей, которые по пьянке тащат домой всё что под руку попадётся.
В этом суть монолита: omnia mea mecum porto.
Всё что мы можем сделать так это оказаться подальше когда всё это лопнет.
Монолитные ОС это про другое вообще-то. А ядро линyпc, судя по всему, будет напоминать гигантскоe лоскутное одело, сшитое из триллиард свистоперделок.
Дружище, ядро можно собрать самостоятельно, без этого модуля. В чем проблема?
Это тебе можно - а он ждет ебилдов. Потому что умеет только на опеннет.
> Дружище, ядро можно собрать самостоятельно, без этого модуля. В чем проблема?Спасибо за информацию, которая всем известна. Проблем нет никаких. Но зачем ты это написал?
Речь вообще не об этом идёт. Речь о том, что персонаж выше использовал слово "монолит" совсем не к месту. Ядро Linux - не монолит.
> Ядро Linux - не монолит.Вы хотите сказать, что все драйверы устройств, файловые системы и сетевой стек перенесли в юзерспейс? Вот я блин проспал революцию...
> Вы хотите сказать, что все драйверы устройств, файловые системы и сетевой стек
> перенесли в юзерспейс? Вот я блин проспал революцию...Можно даже ядро Linux в юзерспейсе запустить, как обычный ELF. UML это называется.
Модульность не противоречит монолитности, это отдельная категория.Что не-монолитное в ядре Linux? FUSE? :)
Вообще кому сильно надо - есть и юзерспейсные сетевые стеки, и ФС в юзерспейсе, и даже работа с девайсами из юзерспейса, если очень хочется.Но вот посмотришь потом с какой скоростью работает exFAT через FUSE и с какой нативно в ядре - и пойдет FUSE-версия exFAT'а на полку истории. К микроядрам и прочим.
> А ядро линyпc, судя по всему, будет напоминать гигантскоe лоскутное одело, сшитое из
> триллиард свистоперделок.Оно и напоминало. Потом разработчики набили руку, научились как делать не надо, отрефакторили много чего. Исторических артефактов еще довольно много, но уже и архитектура прорисовывается, и майнтайнеры умеют делать чтобы их подсистемы хорошо работали, отвечая за это головой. И все такое. А если кто думает что может лучше - какие проблемы? Компилер в руки и вперед.
Ну нифига себе. Это "что попало" одна из лучших, если вообще не лучшая реализация. Если не это то что ж тогда вообще в ядро принимать.
А самый лучший тетрис когда войдёт в состав ядра?
Может эта штука и лучшая в своём классе, но к ядру-то какое она имеет отношение?
Перебрасыватель сетевых пакетов между очередями должен находиться в ядре, потому что перебрасывать сетевые пакеты между очередями — это функция сетевого стека, который является подсистемой ядра (по крайней мере, когда речь идёт о монолите).
> речь идёт о монолитеМонолит на то и монолит, что он не предполагает модульность (иначе он перестанет быть монолитом). Любая монолитность противоречит самой сущности ядра linux, которое самое по себе имеет модульную структуру. Так что все эти патчи с реализациями VPN-интерфейсов в ядре - полный бред имхо.
Витя, держи себя в руках блин, никто не трогает твою модульность.Не хочешь wg в свое едро - menuconfig в помощь. Никакой монолитности!
> Не хочешь wg в свое едро - menuconfig в помощь.Зачем ты это пишешь? Речь не о menuconfig и не о возможности сборки своего ядра. Речь о том, что люди слово "монолитность" используют совсем не к месту и не в попад.
> Витя, держи себя в руках
Геннадий. Если не куришь - бросай и пить. Сначала разберись о чём разговор, а потом выплёскивай совй манямирок.
> Любая монолитность противоречит самой сущности ядра linux, которое самое по себе имеет модульную структуру.Обколются своей марихуаны и давай комментарии писать на опеннете.
Монолитность и модульность - это не взаимоисключающие понятия. Монолитное ядро может быть разделено на модули, которые могут быть загружены и выгружены. Каждый из модулей выполняется в пространстве ядра.
Монолитность и микроядерность взаимоисключающие. Микроядро реализует IPC и других базовые функции, в то время как модули микроядра выполняются в юзерспейсе.
Есть еще такое маркетинговый единорог, как "гибридные ядра" - это, по сути, монолитное ядро, которое имеет API для написания модуля для подключения через нативный интерфейс (в пространство ядра) или внешний API (для юзерспейса).
Давно предпринимаются попытки добавить это в Linux, чтобы сделать его "гибридным", но это очень сложно, потому что добавить IPC в ядро для самого ядра... ну там уже есть и SysV IPC, и POSIX IPC, и не все задачи IPC они покрывают, а добавить еще один IPC, который не будет справляться со всеми задачами, но который нужно поддерживать годами - это не вариант. Вон red hat пытался туда kdbus засунуть, не вышло (слава Аллаху). Теперь вот bus1 засовывают. Но даже несмотря на наличие IPC, коих там и так в ядре имеется, ядро не перестанет быть монолитным.
> VPN-интерфейсов в ядре - полный бред имхо.
Пфффф... То есть наличие ipsec в ядре КАЖДОЙ монолитной операционной системы - это норма (и суровая реальность), а вот WireGuard - это бред?
Единственное, что тут бред - это ваши комментарии.
> WireGuard - это бред?Разумеется это бред. Так как речь идёт не о монолитной архитектуре, а о ядре Linux, разработка которого предполагает модульный подход. Когда мы говорим о монолитных ОС - им свойственнен монолитный подход. Одно дело, когда мы имеем NetBSD, где из коробки должно быть всё представлено. Так как это монолитная ОС, другое дело - ваше лоскутное одеяло, которое противоречит своей собственной модульной философии разработки. Учитывая, что сейчас в ядро усиленно лезут любители смузи (и не только в ядро - яркий пример подсистема днс в ненужнод), я совсем не удивлён происходящему тотальному идиотизму. Но ты продолждай писать простыни демагогии.
> модульный подход.
> монолитный подход
> модульной философии разработки
> лоскутное одеяло
> лезут любители смузиДемагогия - это всё что ты написал. С философиями и словоблудием тебе бы на гумфак.
Linux - это монолитное ядро, разделённое на модули. При разработке минимальным элементом является patch. Патчи с изменениями накладываются на имеющиеся модули, добавляют или даже удаляют их. Ты удивишься, но патчи точно так же можно прислать и в *BSD.
> Одно дело, когда мы имеем NetBSD, где из коробки должно быть всё представлено.
*BSD - это Software Distribution. В них есть понятие базовой системы, которая, на минуточку, никакого отношения к ядру не имеет. И loadable-модули в них тоже есть. Разделение существует только на уровне твоей больной фантазии.
> ненужнод
Это попытка redhat внедрить понятие базовой системы для дистрибутивов линукс по принципу *BSD, никакого отношения к ядру Linux и его модульности этот проект не имеет.
> речь идёт не о монолитной архитектуре, а о ядре LinuxЖдём вашу версию диаграммы https://upload.wikimedia.org/wikipedia/commons/d/d0/OS-struc...
> речь идёт не о монолитной архитектуре, а о ядре Linux, разработка которого предполагает модульный подход.Ты сейчас путаешь тёплое с мягким. Монолит -- это об адресном пространстве ядра, в linux'е оно одним куском, монолитом. Этот монолит противопоставляется микроядру, где на каждый чих создаётся отдельное адресное пространство и код, работающий в нём, не может обратиться к памяти за пределами этого адресного пространства.
А модульность -- это свойство ядра, которое микроядру достаётся легко, в силу того, что ядро уже попилено на кусочки, и большинство из них вне ядра. В монолитном же требуется отдельно над этим работать. Модульность -- это о том, что функциональность попилена на кусочки, которые можно подгружать или не подгружать. В линуксе можно ещё и выгружать. Но писечка-то в том, что эти модули грузятся в то же самое монолитное ядерное адресное пространство.
> Монолит на то и монолит, что он не предполагает модульность (иначе он перестанет быть монолитом).Идите Википедию подправьте, а то они не в курсе
> На сегодняшний день Linux — монолитное ядро с поддержкой загружаемых модулей.
Ну и английскую тоже
> The Linux kernel is a free and open-source, monolithic, Unix-like operating system kernel.
Оказывается, весь мир ошибается в определении монолитности, и только вы знаете Истину. Так спешите же её донести!
> Может эта штука и лучшая в своём классе, но к ядру-то какое она имеет отношение?Простое: VPN целиком о том чтобы брать пакеты и что-то с ними делать. Ну например читать из интерфейса, как-то обрабатывать и закидывать результат в сетевой стек. В случае юзерспейса получается довольно много оверхеда даже в монолитной ОС. А в ядре - ядру не требуется себя изолировать от самого себя, поэтому ядерная реализация просто идет и делает то что хотела сделать с этими пакетами. Без камасутры с копированием в юзерспейс по 5 раз.
Я лучше SoftEther, ничего не видел, а OpenVPN какой замечательный и т.д. и т.п. этот список можно продолжать долго. С чего это WireGuard стал лучшим?
А скорость из-за userland <-> kernel не пробовал сравнить?
Неужто вы провели полноценное тестирование различных реализаций VPN, на разных каналах связи при разных условиях? Не поделитесь результатами? Очень взглянуть хочется!
Для того, чтобы убедиться, что 3>1, не нужно проводить экспериментов. Юзерспейсная реализация всегда будет cливать ядерной, это простая арифметика.
скажи это мужикам из DPDK
Они в курсе, именно по этому и пилят свою бабалайку
Стало быть результатов исследования у вас нет, так и запишем.
А как там ограничением потребления ресурсов - система колом не встанет, если нагрузка ОООЧЕНЬ большая станет ? Ядро же.
>вы провели полноценное тестирование различных реализаций VPNКстати, тут они намеряли 257 мегабит у OpenVPN я даже до 30 мегабит не смог его разогнать, хотя потратил в свое время целый день. По tcp и через http-прокси, правда.
у OpenVPN ровно один плюс, он умеет через наты и через http-прокси. Остальное минусы...
у меня без проблем тянет чуть более 40 мб/с. Меня эта скорость устраивает, нагрузка на сервер и клиенты небольшая.
> у меня без проблем тянет чуть более 40 мб/с. Меня эта скорость
> устраивает, нагрузка на сервер и клиенты небольшая.И дыры в openssl надо каждый месяц латать - иначе сервак разнесут хакеры. Спасибо, блин, за такой подарок в сетевом софте.
Более 100 мбит вполне реально выжать, но нужно шаманить с txqueuelen, sndbuf/rcvbuf и MTU.
А WireGuard просто работает...
Здесь кое-что полезное по теме написано
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_...
> Здесь кое-что полезное по теме написаноЕдинственное чего полезного и по теме openvpn может сделать - переписать свое добро заново и с нуля. Положив на SSL и изначально ориеентируясь на производительность а не баззворды.
положив на ssl - напишешь точно такую же васян-ориентированную фигню, как и wg. С аж двумя сомнительной надежности криптоалгоритмами.Васянам, наверное, сойдет, а у openvpn несколько больший круг пользователей. Попробуй-ка без openssl сделать авторизацию с использованием сертификатов?
Собственно, нечто похожее сделали с openssh. Результат весьма так себе, при том что и задача в разы проще, и оно уже один раз работало без libssl/libcrypto - до загребущих ручек опенка.
> положив на ssl - напишешь точно такую же васян-ориентированную фигню, как и wg.Васян для себя прогает лучше чем энтерпрайзные кодеры на продажу. Проверено Торвальдсом и плеядой компаний которые он вынес.
> С аж двумя сомнительной надежности криптоалгоритмами.
Если уж мы об этом:
1) SSL может подсунуть фуфельные алгоритмы если прогер не позаботится явно. В зависимости от over 9000 факторов.
2) Авторы openssl делом доказали что они - криптодилетанты.
3) CVE в openssl - спасибо если не раз в месяц. В том числе и из-за 2).
4) В SSL/TLS официально бывают интересные вещи типа DES с 40-битным ключом и прочие NIST'овские кривые, а PFS - опция, где-то там. А поверх UDP это вообще заводится с тем еще бубном и массой приколов. Так что разглагольствовать о его безопасности может только профан.
5) А заодно у openssl невменяемое апи, которое секурно использовать даже гурам напряжно, а если кто не профессиональный криптограф - упс. С другой стороны, у той подборочки алгоритмов и апи под стать с этим все намного лучше. Оно сделано так что накосячить особо негде. Designed by comittee vs designed by cryptographer - разница.> Васянам, наверное, сойдет, а у openvpn несколько больший круг пользователей. Попробуй-ка
> без openssl сделать авторизацию с использованием сертификатов?При том в дефолтном конфиге именно эта конфигурация - позволяет обычному юзеру срубить нефиговых лулзов. Трахнув энтерпрайз во все щели. Теоретически, админ может и законопатить дыру, конечно. Практически - он для этого должен хорошо разбираться в SSL/TLS вообще и в сертификатах в частности. А дефолтный конфиг почему-то весьма уязвим.
> Собственно, нечто похожее сделали с openssh. Результат весьма так себе, при том
> что и задача в разы проще, и оно уже один раз работало без libssl/libcrypto
> - до загребущих ручек опенка.Не понял этих реверансов. У ssh как протокола даже у самого по себе хватает косяков - довольно много данных течет, например. Если к этому приплюсовать еще и вулны openssl - как-то совсем не здорово. И что такое загребущие руки опенка? Они вроде и начинали openssh кодить? А то что у них наконец приступ адеквата начался и они заметили что openssl как либа ужасна - поздравляю, доползло!
>Я лучше SoftEther, ничего не виделА вы хоть одним глазком на его исходники поглядели? Очевидно, что его вантузы пишут, а у них не особо принято заботится о безопасности.
Я поглядел. Очешуел и стер к чертям. Нельзя так сетевые программы писать.
Мне одной попытки настроить SoftEther хватило, чтобы понять, насколько этот кусок софта не предназначен для использования людьми
Адская энтерпрайзятина. С огроменным кодом. Делающая черт знает что. Парит, жарит, крестиком вышивает. И дыр наверняка из-за этого просто море. Большому коду - много багов.
> Я лучше SoftEther, ничего не виделОгромный монстр с кучей хлама. В код смотреть - страшно.
> OpenVPN какой замечательный и т.д.
Пока на код и производительность не посмотришь.
> С чего это WireGuard стал лучшим?
1) Хорошая подборка крипто.
2) Можно сделать с минимумом зависимостей, втч изза 1).
3) Довольно шустрый, в тч изза 1).
3) Довольно просто настраивается, с ipsec не сравнить.
4) Не монструозный, кода в десятки раз меньше чем в openvpn и прочих софтэзерах. Изза 1).
5) Обычный UDP, не требующий к себе специального внимания сетевых железок.
Да просто гениальная, только по TCP работаь не умеет, ниче что все фаерволлы наглухо блочат udp
Не надо врать, мой не блочит.
А что твой это = все?
А твои - все?
А при чем тут мои? Я говорю про то что разрабы могли бы сделать поддержку 2х протоколов а не одного. В ином случае смысла от wg за фаерволлом становится ноль.
Настрой свой фаервол и не морочь людям голову. А так-то можно и TCP зарезать по самый HTTP, к примеру. На каждого больного на голову админа не напасёшся воркараундов.
> Настрой свой фаервол и не морочь людям голову. А так-то можно и
> TCP зарезать по самый HTTP, к примеру. На каждого больного на
> голову админа не напасёшся воркараундов.Ща, погодь, пойдет QUIC в массы, потому что TCP всех уже достал своим поведением в беспроводных сетях - и админы сами все развинтят.
Вообще-то, QUIC жестко завязан на гарантированный порядок доставки пакетов (иначе жёстко тупит), чего в беспроводных сетях нет. В общем, проблем будет даже больше, чем с TCP.
> Вообще-то, QUIC жестко завязан на гарантированный порядок доставки пакетов (иначе жёстко
> тупит), чего в беспроводных сетях нет. В общем, проблем будет даже больше, чем с TCP.Все там будет ок - гугл в состоянии нанять нормальных инженеров, а не таких экспертов с опеннета. Порядок доставления пакетов в целом более или менее сохраняется. Просто потому что сильная буферизация убивает латенси и вообще - нет у этого оборудования столько оперативки чтобы на кучу юзеров кучу пакетов складировать. OpenWRT вообще проводили кампанию борьбы с buffer bloat - это и TCP карму портит. Намного хуже чем любому UDP - в TCP это вообще в ряде случаев проблема, особенно в начале сессии.
Это не говоря о том что роумиться ванильный TCP не умеет как класс. Поэтому при переключении сетей - tcp конекция отвалится. И пока оно там прочухает - для VPN это в динамичном мобильном окружении получается очень уж паршиво.
Я, например, использую vpn для хождения через _чужие_ сети, т.е. там, где файрвол не настроишь. И да, могу подтвердить - блочат все кому что не лень. Поэтому приходится держать и WG и OpenVPN на TCP на 443 порту.
> Поэтому приходится держать и WG и OpenVPN на TCP на 443 порту.Hint: есть такой порт, 53. Довольно часто не зафайрволен. Сам не понимаю почему.
>> Поэтому приходится держать и WG и OpenVPN на TCP на 443 порту.
> Hint: есть такой порт, 53. Довольно часто не зафайрволен. Сам не понимаюон довольно часто проксится на собственный сервер.
Правда, правильному туннелю это не мешает, но его мало кто планирует у себя поднимать.
> он довольно часто проксится на собственный сервер.натурные эксперименты показали что админы слишком ленивы, к тому же всякие captive совершенно точно 443 не забудут - так слишком очевидная и массовая халява. а вот полтора извращенца с тоннелем на 53... мало кого интересуют. во всяком случае до тех пор пока не начинают офигевать и качать через халяву какие-нибудь торенты оптом, там админы напрягутся по деградации сервиса или оплате трафика. и то 50/50.
> А что твой это = все?Раз мой не блочит, значит, ваше утверждение, что "все блочат" — вpаньё.
Чтобы опровергнуть предикат с квантором всеобщности, достаточно предъявить хотя бы один объект, для которого он даёт результат "ложь".
Кстати да, у клиентов, которым даём впн через SoftEther, иногда не проходит коннект. Решается переключением на 443/TCP. За пару лет таких случаев было около 5, но тенденция удручающая.
Заблокированный UDP в эпоху QUIC и HTTP/3 - это либо жестко закрученные гайки в плане безопасности, либо упоротые админы. Ни на одно, ни на другое не стоит равняться.
Если вдруг нарвались на подобную сеть, то есть udp2raw, Shadowsocks и SSH-туннели. Можно, конечно, взять TCP-шный VPN, но man Why TCP Over TCP Is A Bad Idea и другие проблемы.
И безопасность, и упоротые админы которые хотят что бы и другой трафик в их сети ходил. А не только гуглосайты.
>Заблокированный UDP в эпоху QUIC и HTTP/3 - это либо жестко закрученные гайки в плане безопасности, либо упоротые админыДля физлица васяна хороший VPN это тот, который будет работать везде, в любой кафешке, первом попавшемся открытом wifi или через модем. А не тот, у которого скорость 100500 мегабит. Здесь openvpn царёк.
А для юрлиц хороший VPN это скорость. ipsec уже есть. у wireguard тут шансы есть.
А сразу на два стула не сядешь...
ровно наоборот - васяну надо чтоб торрент-шморрент побыстрее, пока из кафешки не погнали.А для юрлиц - rdp пролазит - сойдет.
А те vpn, которые у них критичны к скорости - выглядят вовсе не васян-поделками на линуксах (и, как правило, вообще без шифрования - дорого и ненужно, а часто и нереально в принципе - растянутый cross-dc san, к примеру)
А насторойка IPSEC это секас под бубен.
Если речь о клиенте, то настраивается в два клика в морде NetworkManager'а.
Веселье начинается, когда DPD выгоняет этого клиента на мороз, а ikelifetime не позволяет ему подключиться обратно.
На самом деле, настройка IPsec требует некоторых базовых знаний протокола IKE и механизма XFRM, ну и маршрутизации до кучи.
Но для современных "админов" почитать документацию — сложнаа, они умеют только из гугла копипастить и о «философии unix»™ глубокомысленно рассуждать. Если для использования инструмента нужно читать ман — это уже «переусложнённый комбайн»®, и в Великом Линуксе ему не место.
> гугла копипастить и о «философии unix»™ глубокомысленно рассуждать.Философия *nix между прочим, о том что программа делает 1 вещь и делает ее хорошо. Мне этот принцип нравится. И wireguard в него более-менее вписывается. А ipsec делает черт знает что, черт знает зачем. И документацию на это пусть читает тот, кто понимает зачем оно такое бессмысленное и беспощадное в таком виде вообще было надо. Не зря Торвальдс в рассылке в свое время отписал что по сравнению с ipsec и openvpn - это просто шедевр. На самом деле скорее это правда openvpn и прочие ipsec ужас, а это просто нормально сделаный впн. С задействованием головы, а не той части тела которая протирает энтерпрайзный стул.
> Философия *nix между прочим, о том что программа делает 1 вещь и делает ее хорошо.Внезапно, IPsec соответствует этому принципу лучше, чем OpenVPN и сабж, потому что не занимается организацией туннелей и согласованием ключей. Туннели — это одна вещь, шифрование трафика — другая, ключи — третья. Можно сделать GRE или IPIP туннель без шифрования, а можно сделать шифрование без туннеля на IPsec ESP. А можно совместить и получить IPsec с VTI/XFRM vif.
> А ipsec делает черт знает что, черт знает зачем. И документацию на это пусть читает тот
Вечная участь программа построенных по философии unix — они не нужны 95% юзеров. Пипл хавает комбайны, которые работают из коробки. А при действительно серьёзном отношении к архитектуре приложения, с изкоробочностью обычно всё плохо.
В случfе с IPsec, проблема "одминов" обычно в том, что они пытаются применить traffic selector как правило маршрутизации, зачастую вообще не представляя себе, что такое security associations. И закономерно лососают, а потом идут всем рассказывать, как IPsec неюниксвейный.
> Внезапно, IPsec соответствует этому принципу лучше, чем OpenVPN и сабж, потому что
> не занимается организацией туннелей и согласованием ключей.Принципы не выбиты в камне - логично выбирать те, которые в конкретной ситуации работают хорошо. Я настраивал ipsec - и мне это очень не понравилось! Все сложно, мутно, неочевидно. А после всех мытарств узнаем что у решения плохая совместимость с сетевым оборудованием, криптография мутная, а объем кода таков что про эффективный аудит 1 человеком или небольшой командой речи не идет. Зато идет речь про attack surface, если не бэкдоры NSA в алгоритмике.
> Туннели — это одна вещь, шифрование трафика — другая, ключи — третья. Можно сделать
> GRE или IPIP туннель без шифрования, а можно сделать шифрование без
> туннеля на IPsec ESP. А можно совместить и получить IPsec с VTI/XFRM vif.Теоретически все так, а практически получаем другую проблему - комбинаторный взрыв на границах взаимодейтсвия. Получается как в микроядрах - вроде здорово, все по мелким независимым модулям распихано, но в целом пакость работает так что даром никому не надо. Вот ipsec очень в духе получился - поверх существующей инфраструктуры с минимальными проблемами не заводится. И создает больше проблем чем решает.
Поэтому для себя под "1 вещью" я буду считать не туннель. И не шифрование. А таки "VPN". Подразумевая более-менее типовой набор свойств. Нет, "VPN" без шифрования я всерьез рассматривать не буду - это на мое мнение годится разве что для коммуникаций в пределах 1 ДЦ, желательно целиком своего, и даже так - с оговорками. А сети видите ли не очень дружелюбная среда и там с трафиком может твориться что угодно. Поэтому без нормального крипто это просто не проходит минимальные требования и ведет к угрозам безопасности.
> Вечная участь программа построенных по философии unix — они не нужны 95% юзеров.
У философии *никс есть сильные стороны и слабые. Я предпочитаю пользоваться сильными, а если натыкаюсь на слабые - то не испытываю проблем взять и пересмотреть подход. Если гвоздь хреново закручивается отверткой - возьму молоток.
> Пипл хавает комбайны, которые работают из коробки. А при действительно
> серьёзном отношении к архитектуре приложения, с изкоробочностью обычно всё плохо.Тут можно поспорить о том насколько далеко надо расщеплять "1 вещь". Даже тот же ls делает довольно много всего и таки тоже комбайн. Можно поспорить что для просмотра имен файлов должна быть одна прога, для просмотра размеров - другая, а права смотреть - третьей. А ls -la дескать надругательство над *nix way. Для "VPN" мое мнение см. выше.
> В случfе с IPsec, проблема "одминов" обычно в том, что они пытаются
> применить traffic selector как правило маршрутизации, зачастую вообще не представляя себе,
> что такое security associations. И закономерно лососают, а потом идут всем
> рассказывать, как IPsec неюниксвейный.А еще оно просто не пролазит через половину оборудования. Ну да, потом кто-то затрахался и придумали костыли с энкапсуляцией в udp. И что получаем? Аналог wireguard из веревочек и палочек? Мутный, с кучей кода и сложный в настройке? И зачем бы он такой?
И поиметь тотальную просадку, ну ниче так совет
Просадку? Что?
> ниче что все фаерволлы наглухо блочат udpНу допустим не все. И вообще, файрволы разные бывают. С GFW например мороки довольно много, но он в основном создает проблемы массовым платным сервисам, их видно по толпе юзеров которые туда ломятся.
Интересно, насколько пострадала производительность по сравнению с API Zinc. Если останется dkms-версия с Zinc - лучше буду использовать её.
Давеча тестил boringtun из aur, то даже он немного медленнее. Скорее всего это в пределах статистической ошибки, но хз.boringtun
86 packets transmitted, 86 received, 0% packet loss, time 17072ms
rtt min/avg/max/mdev = 22.419/23.009/28.364/0.791 ms
standard
90 packets transmitted, 90 received, 0% packet loss, time 17868ms
rtt min/avg/max/mdev = 22.272/22.911/27.661/0.606 msДумаю, если у Доненфелда были претензии, то таки медленнее
Какой смысл выдавать превосходство над опенвпн за достижение вселенских масштабов?>перевод на штатный Crypto API ядра приведёт к ухудшению показателей
Какой смысл мухлевать и пропихивать заранее зная что цифры не правдивы?
пропихнуть попытались как раз с теми самыми цифрами. Разработчики ведра заявили что "не так поклонились", "порежьте помельче и переподайте с земным поклоном, а не поясным".Поскольку автор, увы, искренне верит во всякие gpl-фетиши и хранит глубоко в сердце книжку Рэймонда - он и поклонился, и правильный апи выпилил, и с глубоким почтением - переподал.
Справедливости ради - код zinс c удовольствием раздербанили авторы текущего kernel api. Что-то, наверное, даже улучшится.
> Что-то, наверное, даже улучшится.Ну так в кернеле и не только - довольно много юзерей кода. И если каждый будет волочь все что ему вздумается, не заморачиваясь тем чтобы и остальные этим могли пользоваться - во что оно превратится? В кадавра с многократным дублированием явно библиотечного кода? Разработчики линха не настолько дилетанты в управлении проектом чтобы это допустить.
тесты быстродействия, надо понимать, сделаны с zinc api. Т.е. текущая реализация навряд ли окажется быстрее ipsec.С формальной верификацией тоже можно проститься.
Мораль: новость хорошая для автора, а остальным лучше пока пользоваться версией, отдельной от ядра.
Большую часть zinc интегрировали в крипто. Собственно, это было самым сложным этапом и заняло больше года.
> После несогласия разработчиков ядра с подобным предложением и переговоров на конференции Kernel Recipes, создатели WireGuard в сентябре приняли решение перевести свои патчи на использование имеющегося в ядре Crypto API, к которому у разработчиков WireGuard имеются претензии в области производительности и общей безопасности. После того как эта работа была выполнена и были учтены замечания по оформлению кода, патчи были одобрены для принятия в основной состав ядра.Что? Буквально в ноябре всё поменялось https://lists.zx2c4.com/pipermail/wireguard/2019-November/00...
it turns out that at the same time as I
was stepping toward compromising and using the old crypto API here
with this thread, other kernel developers were interested in
compromising to upstream some aspects of Zinc. The result is that
everybody took constructive steps toward each other, and the first
part of Zinc has been merged
Кстати да, читая эту статью, вспомнил, что dkms у арча при ребилде иногда выдавал, что в ядре уже есть готовый модуль. С политикой арча, очень сомниительно, что они бы тащили Zinc в ядро.
Наконец-то!
Да будет VPN via UDP без геморроя во время обновлении ядра! :-)
А чем не устраивал IPSec over UDP?
> А чем не устраивал IPSec over UDP?неимоверно сложным, плохо совместимым с другими реализациями и регулярно оказывающемся дырявым демоном, требуемым для его запуска, например?
Причем никакой безопасности все эти энтер-прайсные навороты совершенно не добавляют.
> неимоверно сложным, плохо совместимым с другими реализациями и регулярно оказывающемся дырявым демоном, требуемым для его запуска, например?Хм.
> Поддержка WireGuard уже интегрирована в NetworkManager и systemd
Это лучше и безопаснее, чем strongswan?
> Это лучше и безопаснее, чем strongswan?так его поддержка - туда же - давно интегрирована...
(через кривой плагин, кстати, разные версии совместимы с разными версиями nm)
Именно поэтому занесенный в корпоративный RADIUS клиент может просто вбить свои логин-пароль в настройках соединения и подключиться к рабочей сети.> (через кривой плагин, кстати, разные версии совместимы с разными версиями nm)
С libre/open swan были грабли, а strongswan просто работает независимо от версии NM.
IPSec - это, вкратце, набор костылей для улучшения кучи ранее существующих решений, среди которых Sec лишь в названии.
WireGuard - написанная с нуля, простая и надёжная реализация того, что мне нужно, изначально на эффективном и безопасном шифровании, без излишеств и обязанности быть совместимым со старым интерпрайзным дерьмом.
Выбор очевиден!
опеннетовский специалист-по-всему в треде, ныкаемся, пацанчики!
> IPSec - это, вкратце, набор костылей для улучшения кучи ранее существующих решений, среди которых Sec лишь в названии.А вот лучше бы поподробнее, а то получается что вы считаете неэффективным тёплое, потому что вам нужно мягкое. WireGuard это явный прогресс по сравнению с тем же OpenVPN, но нет никакого смысла делать WireGuard там, где требуется GRE over IPSec и совместимость с ентерпрайзным железом.
> там, где требуется GRE over IPSec и совместимость с ентерпрайзным железом.Там где все это требуется, есть и пяток админов морально готовых к занятию со всем этим непотребствами, без вазелина. А потом вся эта айписятина застрянет в первой же кафушке у выездного сотрудника.
> А потом вся эта айписятина застрянет в первой же кафушке у выездного сотрудника.Это одноранговые туннели, выездные сотрудники таким не пользуются, это для соединения кучи филиалов и подразделений. Выездные пользуются в таком случае обычно отдельно стоящим openvpn или проприетарными аналогами.
> Это одноранговые туннели, выездные сотрудники таким не пользуются,Это только у огромных энтерпрайзов, у которых есть ресурсы на дюжину сапортов, тиму админов, emergency responce team и чего там еще, способные нарулить свой CA и сколь-нибудь внятно (или не очень) это содержать. Ну там да, можно и так, конечно. Саппорт все стерпит. Ну или накрайняк сдернут другого человека с другого проекта - в транснациональном монстре так можно.
> WireGuard это явный прогресс по сравнению с тем же OpenVPN, но нет никакого смысла делать WireGuard там, где требуется GRE over IPSec и совместимость с ентерпрайзным железом.Ну вообще для site2site wireguard как раз наиболее просто и приятен. Это с road warrior конфигурацией много проблем (ну, пока мы все на IPv6 не перешли).
>А чем не устраивал IPSec over UDP?Геморроем.
А фаерводчик то тебя подрежит с твоим удобством
>в Crypto API уже включены подготовленные в WireGuard быстрые реализации алгоритмов ChaCha20 и Poly1305.дооптимизируются, блин. Только удаленно эксплуатируемых атак по сторонним каналам не хватало.
Ну, для ядра, которое в VPN закидывает пакеты из других интерфейсов в обход шифрования, это не самое страшное зло. :)
Это, вообще-то, стандартный алгоритм маршрутизации. Реализован не только в линуксе.
Разработчику захотелось смотреть Netflix из другой страны без тормозов. Набросал WireGuard - по сути для решения одной этой задачи. Как следствие, таща минимум зависимостей и имея минимум сложностей с запуском. Хипсторы раскудахтались: гениальное изобретение! Инженер с большой буквы! То, что большинству людей это попросту было не нужно, поэтому и не делали - им и в голову не приходит. А вот кричат громче всех, создавая видимость прорыва в технологиях. Ничего кроме фейспалма это не вызывает.
>То, что большинству людей это попросту было не нужно, поэтому и не делали - им и в голову не приходит.Количественно это большинство как выглядит? И сколько там есть компетентных в этой сфере сишников? А то я знаю некоторых личностей, которым в голову приходят только сигналы только от ВНС.
Если так подходить к каждой проблеме, то у нас вообще ничего не будет — колесо ведь тоже изобрели "по сути для решения одной этой задачи".
> Если так подходить к каждой проблеме, то у нас вообще ничего не будет — колесо ведь тоже изобрели "по сути для решения одной этой задачи".Это повод хайповать? (пинок за невнимательность/желание видеть то, что хочется видеть в комментарии собеседника)
это повод возмущаться чьей-то радостью? (пинок за невнимательность/желание видеть то, что хочется видеть где угодно и решать, что кому нужно)
Ведь я теперь могу смотреть нетфликс из другой страны без тормозов и мне даже не надо писать для этого модуль ядра. Было бы там десять строк на баше, я бы тоже не был в восторге. Хотя допустим в debian есть куча мелких скриптов, которые простые, но удобные.если более конкретно поговорить про желание что-либо видеть в коментарии, то там например может быть:
- попытка указать людям, что делать
- отсылка к отсутствующим здесь людям (я сомневаюсь, что проводился опрос)
- уязвленное самолюбие
- плохое настроение из-за просроченной пиццы
т.к. технического в нем ничего нет.ну и это ваше
>Набросал WireGuard - по сути для решения одной этой задачи.Ну так у большинства одна задача — смотреть нетфликс. Не вижу противоречий: решение есть, большинство довольно.
PS: себя я запишу в большинство, если позволите.
> это повод возмущаться чьей-то радостью?Это повод считать радующихся не очень умными людьми. Хорошо если 1% радующихся используют WG по назначению для которого он был создан, для остальных это просто мода, незнание истории и области VPN-технологий.
А что касается простоты - у меня первый раз OpenVPN быстрее удалось поднять, чем первый раз WG.
> Ну так у большинства одна задача — смотреть нетфликс.
Азаза.
>Это повод считать радующихся не очень умными людьми.ну так научи. Я с радостью прочту интересную статью про цели создания WG и область его использования. Ну там сравнение плюсов-минусов различных решений в различных условиях. Ведь это будет полезнее комментария "большинству не нужно".
>у меня первый раз OpenVPN быстрее удалось поднять, чем первый раз WG.
у меня тоже. Я тупо конфиг скопировал не разбираясь и оно как-то заработало, а с WG так почему-то не прокатило, пришлось чутка покомпилировать и почитать.
>Азаза.
а что, большинство впны админит что ли?
> Ведь это будет полезнее комментария "большинству не нужно".Повторю, это твой комментарий, не мой. Мой - о хайпе, который устроили хипстеры для рядовой технологии. На случай если ты действительно разучился читать.
нет твой :p
> Разработчику захотелось смотреть Netflix из другой страны без тормозов.для этого, внезапно, не нужно шифрование - вообще. Обычный ipip туннель спас бы от несуществующих "тормозов". (способности видеотракта переваривать траффик обычно на два порядка ниже способности сетевой его передавать)
Окей, злой провайдер резал ему непонятные протоколы - все еще можно было, вместо того чтоб его поменять, написать свою реализацию незамысловатого l2tp (та что в линухе, признаемся, г-но полное) - опять же не нуждающуюся ни в сложной авторизации, ни в шифровании - один хрен нетфликса имеет собственное.
> То, что большинству людей это попросту было не нужно
большинству виндоюзеров вообще этот ваш линух не нужен.
Они свои видосики в тентаклике с хипстаграмчиком и под родной десяточкой посмотрят.
> для этого, внезапно, не нужно шифрование - вообще.С учетом количества 3.14...сов которые хотят совать свой нос, а то и руки в траф - оно таки очень даже пригодится.
> большинству виндоюзеров вообще этот ваш линух не нужен.
Так их никто и не заставляет. Вот им в такой конфигурации шифрование не поможет - они и так майкрософту нажатия кнопок на сервер слили.
> Они свои видосики в тентаклике с хипстаграмчиком и под родной десяточкой посмотрят.Они видите ли пиндеть изволят когда сотовый оператор врезает им попадосную рекламу в страницу. Поэтому vpn который от этого не защищает - не надо даже им. Они за такую услугу платить не будут. А вот за защиту от такого - вариант.
это как с пропихиванием системдэ -- "теперь всё точно будет быстро!" (с) Похоже скоро и Защитник Шиндошс добавят.
Кому не нравится насильственное пропихивание — уже давно свалили на винду-десятку. Там ни пульсы, ни системды, ни wireguard. И главное — никто и никогда не будет их туда портировать. Свобода, безопасность, юниксвей!
вот не надо - единственная внелинуксная реализация вайргада как раз - под десяточку.
Правда, афтар ее всячески обсирает, намекая на зонды, происки товарищмайора и что деньги лучше бы отдали бедным (сам он искренне верующий и денег ему не надо, он и свои пожертвовал на храм FSF)
А где про это почитать? Очень интересно стало что этому композитору вот тут https://github.com/TunSafe/TunSafe не хватило.
> А где про это почитать?ругань в их адрес - где-то вокруг самого сайта wireguard, разумеется.
Аффтар очень красочно расписывал, почему это кг/ам, и что он один только весь в белом.
Я, естественно, не слишком проникся, поскольку меня в общем и оригинальный креатиф не особо впечатлил, поэтому и не стал запоминать детали.
> единственная внелинуксная реализация вайргада как раз - под десяточку.Nix on Darwin
FreeBSD
OpenBSD
macOS Homebrew and MacPortshttps://www.wireguard.com/install/
Зачем ты постоянно врешь?
ну ок, я рад за афтара что он наконец-то осилил не только кидать какашки в tunsafe, но и запилить свою версию.> Зачем ты постоянно врешь?
я просто не занимаюсь дро4евом на ваш впопенсофт - один раз глянул - линуксонли, на альтернативную реализацию других людей, которые как раз захотели поддержать идею - вылит ушат дерьма, и больше, за ненадобностью, к вопросу не возвращаюсь.
А вы, видимо, не вылезаете с wireguard.com? Извиняйте, у меня других дел есть.
Дакие дела? Круглосуточно писать каменты на опеннете?
Это комьюнити запилило, разумеется.
Что логично. Под Винду пилит тот, кому она нужна.
уже выпустили оффициальный клеент под вантуз, но надо же пiкнуть в лужу
> уже выпустили оффициальный клеент под вантуз,всем пох..й.
Кому страсть как хотелось вайргада в десятке - давным-давно пользовался неофициальным, а не ждал джва года.
> уже давно свалили на винду-десятку. Там ни пульсы, ни системды, ни wireguard.Ну это не совсем неправда.
https://tunsafe.com/download
https://www.wireguard.com/install/
https://www.freedesktop.org/wiki/Software/PulseAudio/Ports/W.../
Ну вот никак не получится не загружать модуль или отменить запись файла модуля на диск, а если не установишь, то и система загружаться не будет.Разработчик старательно ведет переписку, переделывает и присылает патчи снова, ищет компромисс — ну точно как системдэ.
Как быть с разделом "Work in Progress" https://www.wireguard.com/#work-in-progress, который говорит о том, что еще не готово?
Работа над разделом "Work in Progress" ещё не завершена.
А почему функции API Zinc нельзя было добавить в Crypto API? Почему он должен был заменить его?
> А почему функции API Zinc нельзя было добавить в Crypto API? Почемупотому что он простой, дубовый и в многоуровневой этажерке crypto api не нуждался, чем и был, единственно, хорош.
Но у него был один существенный недостаток - отсутствие не-djb протоколов.
а сами низкоуровневые реализации - вон, во всю копипастят.
Wireguard под управлением PKI - туннельные ключи генерятся динамически, основываясь на (само)подписанных сертификатах.
молодцы, весь смысл проекта свели к х..ю.
Вам racoon2 было мало, с сертификатами, блэдкжеком и так далее?
управлять сертификатами проще чем с ключами wireguard, особенно когда клиентов много планируется- не находите?
Отозвал сертификат и знаешь, что вот этого клиента ты отключил. По крайней мере, я запускал с тремя четырьмя клиентами - удобно. Сертификат (CN) можно привязать к DNS и т.п. плюс если использовать knock с автонастройкой файрволла - сервер впн посторонним практически вообще не виден.
> управлять сертификатами проще чем с ключами wireguard,гм. а наивный автор думал с точностью до наоборот ;-)
Так-то все то же самое умеет любой ентер-прайсный ипсек. А вот быстро без лишней возни поднять надежно защищенный туннельчик точка-точка так же просто, как поднимается какой-нибудь ipip - не умеет. На мой взгляд - ценность вайргада именно в этом.
так вот kurenma позволяет объединить преимущества wireguard и PKI - лишние усилия не возникают, потому как в нем вручную ( или инцидентно - как настроишь) генерятся сертификаты PKI (включая приватный ключ) вместо пары ключей wireguard - та же самая работа или даже приятнее, потому как commonname можно забиндить в dns или еще как заинвентаризировать. Затем уже wireguard ключи генерятся автоматически на каждый сеанс и хранить их не нужно, а вот приватные PKI ключи - как обычно, впрочем и сертификаты тоже разбрасывать ни к чему.
> ценность вайргада именно в этом.Именно. Такой себе дежурный тунель когда надо траф пробросить от A до B без каких-то сильно крутых/специальных требований, но без того чтобы первый же роутер или хакер в кафушке с бесплатной вафлей его нахаляву расхакали. И уж конечно без камасутры как ipsec.
КМК для этого проще всего SSH использовать, не?
Тут именно что branch-офис со скоростью повыше, нежели дает openvpn подключать, если ipсекс на железках по какой-то причине не манит.
> КМК для этого проще всего SSH использовать, не?Именно VPN в ssh - непотребство "для галочки". Зачем они такой реализацией позорятся - я не понял. Там вроде аж PPP гуляет. Первые автомобили так и делали - карета с моторчиком. Но потом дошло что можно и лучше. Кому сейчас карета с моторчиком нужна, кроме музеев? PPP в VPN - туда же.
> Тут именно что branch-офис со скоростью повыше, нежели дает openvpn подключать, если
> ipсекс на железках по какой-то причине не манит.Как по мне - сабж и для просто линковки кучи своих машин в единую структуру неплохо годится. Без всяких бранчей и айписеков, чур меня.
Компромисами выхожена дорога в болото.
Почитайте о недостатках, удивитесь как такое можно вообще даже в юзерспейс допускать https://restoreprivacy.com/wireguard/
Недостатки для анонимного VPN. Это не единственный use-case.
да пофик на анонимность, важна централизация сети, но чтобы центр соответствовал чловечским принципам, что бык данным кторые чрез него проходят, не могли ни какие уроды получить доступ просто потому что у них ксива или удаставирение работника датацентра, и что бы трафик весь сниферится начал исключительно алгоритмами а не глазами чловечского фактора, и если алгоритм что то видит, а они с каждым часом все умнее тода есть сигнал, и идет рассмотрение и только порешению суда чловек, служощий органов или кто там смог бы залезть к тебе в дату. при такой системе мне пофик на анонимность и так аноимней дальше некуда,и именно этот момент меня лично беспокоит а не сама приватность от всего и вся что уроды запаек могут даты вертить на которые им ни какого разрешения не довал убоги они для этого имха слишком, а вот всяким уродам, которых по какой то причине до сих пор общество от нормальных людей не изалировало на основе днк тестов например или псих портретов, сопосбных наносить сознательно вред окружающим и получающих от этого удовлетворение которые всякими малопотребными вещами занимаются в обществе стоит очень сильно поднопрячься потому что ихнии коммуникаци окажутся под конкретным контролем и это хорошо для всего нормального общества не считая тупо фанатиков слова приватность, те продолжут слегка ерзать то психека, но не хорошо для уродов которые больше ни на что не способны только как подсирать остальным используя дату остальных для удовлетворения собственных убогих потребностей.
> Недостатки для анонимного VPN. Это не единственный use-case.Я не понял, куда они логи в diskless сохранять то будут, хоть там что? Ну и таких грабель навалом у любой технологии. Wireguard'а народ тоже причесывать научится. Он пока просто новый и грабли не обтоптаны, о чем честно написано. А так то VPN сервис чудно порекламился - специалисты по приваси качественные, в проблематике шарят.
Ура! Наконец то WireGuard будет в ядре!
Поздравляю создателя!
Блоатварь, а не ядро.
Если выпилить ненужный ipsec, то количество кода в ядре уменьшится.
это просто супер, ждем дальнейших продвижений в том же направлении и стар линк алсо кстати.
Я так понял WireGuard заменит часть программ OpenVPN ? Будет развиваться как отдельный проект не зависимо от состава ядра Linux 5.6. Только часть программ войдёт в состав Ядра а почему они вся прога этого Проекта WireGuard ?
> Я так понял WireGuard заменит часть программ OpenVPN ? Будет развиваться
> как отдельный проект не зависимо от состава ядра Linux 5.6. Только
> часть программ войдёт в состав Ядра а почему ни вся прога
> этого Проекта WireGuard ?
потому что все слишком субъективно, берут только то что может потом легко без всяких дебатов быть освоено и применино в ядре не зависимо от этого проекта, а то кто то сутра передумоет пилить проект и не станет проекта, потом его снова выпиливать, может из за того.
> Я так понял"люди читают жопой.jpg"
> заменит часть программ OpenVPN
нет
> Будет развиваться как отдельный проектнет
> Только часть программ войдёт в состав Ядра
да, потому что, внезапно, ядро не умеет самостоятельно настраивать интерфейсы
учитесь читать, молодой человек.
Чем обоснованны претензии к "общей безопасности" существующего CryptoAPI?
Более быстрая реализация алгоритма вполне может оказаться не безопасной. Аудит проводили? Кто? На чьи деньги? Где отчет?
И почему вдруг VPN не должен уметь TCP? Есть несколько сценариев, в которых использование TCP принципиально. Например неадекватный провайдер, низкое качество канала или обход через прокси.
Они несколько лет пропихивали изменения в двух подсистемах одним проектом? Они серьёзно думали, что получится? Так не делается - один проект пилит CryptoAPI, а второй пилит VPN. Только так. Аргумент "мы запили свою реализацию CryptoAPI, потому, что наш VPN с ней работает быстрее" как минимум не состоятельный. Тут может работать только такой "мы запилили VPN но он работает медленно, давайте перепилим CryptoAPI".
Странная движуха, слишком агрессивная.
>Более быстрая реализация алгоритма вполне может оказаться не безопасной.Это слишком оптимистичная оценка. История учит тому, что если ты не математик-аутист (в хорошем смысле этого слова), то после вот таких "улучшений" крипто-алгоритмов или энтропия ни к черту, или по анализу задержек, и прочим сторонним каналам можно утянуть не сильно меньше чем при использовании XOR вместо ChaCha.
читайте статьи самого Донфельда - они вполне доступны для желающего не позвездить как все плохо, а разобраться - но вы ж не хотите, вам лишь бы обос...ть.> Более быстрая реализация алгоритма вполне может оказаться не безопасной.
более медленная, внезапно, вполне может оказаться еще больше небезопасТной, просто еще и тормозом.
> Аудит проводили? Кто? На чьи деньги? Где отчет?
если бы вы хотели - вы бы его давно прочитали. Кстати, аудит in-kernel криптографии - вообще, afaik, никто никогда не проводил, и написана она так что никакой аудит ей не поможет. Не говоря уже о том что ее все время патчат и улучшают, и аудит по хорошему надо проводить каждый раз.
> И почему вдруг VPN не должен уметь TCP?
потому что протокол tcp писали для вполне фиксированного набора ситуаций, "сеть" с гарантированной доставкой но непредсказуемыми задержками в них не входила - поэтому tcp over tcp работает плохо.
> Есть несколько сценариев, в которых использование TCP принципиально.
в этих сценариях пора уже забыть об эффективности и скорости протокола. Соответственно, данная конструкция для них не предназначена, автор не стремился охватить весь миллион применений. К тому же они все сомнительные - обычно "обход прокси" нужен тем, кто занимается на работе - вредительством.
> Они несколько лет пропихивали изменения в двух подсистемах одним проектом? Они серьёзно
> думали, что получится?да, надеялись на разум - но натыкались на оттопыренные средние пальцы. Получилось в результате - ни богу свечка, ни чорту кочерга. Тем аудитом и доказательством правильности теперь как раз можете подтереться - скажите спасибо героям, истерично заsshitившим ядро от пропихивания неправильным образом.
> Так не делается - один проект пилит CryptoAPI, а второй пилит VPN.
в результате после пары лет переговоров и миллиона правок двумя разными командами - упс, при объединении выяснится что ничего не работает, или хуже - поскольку опять же можно подтереться правильностью неправильно используемых алгоритмов, где-то на стыке появляется уязвимость к sidechannel или вовсе вся криптография представляет собой xor (такое в истории ядра уже тоже было - именно из-за неправильного использования впоне в принципе правильного шифрования).
поэтому tcp over tcp работает плохо - а tcp over udp прямо идеально ага
У меня уже так долго стоит и ниче так.
> поэтому tcp over tcp работает плохо - а tcp over udp прямоа tcp over udp человек с руками и головой вполне да, может сделать практически неотличимым от голого tcp. Включая и работу на каналах с потерями или большой задержкой (не говоря уже о packet reordering), или, наоборот, быстрых линках, где важна малая задержка и джиттер.
Но вы ж не разбираетесь в технологии, да?
Нет конечно я в технологии не разбираюсь, все жду от вас гайда как все это правильно готовить, но что-то пока не вижу его.
> Нет конечно я в технологии не разбираюсь,...то и мнение о том что и как работает высказывать наверное неуместно. Еще более неуместно хотеть после этого гайды. Гайд который после такого поведения можно услышать может звучать довольно невкусно.
Маладца, поумничал, на конфетку... гайда все еще нет? Ну тогда пи..дабол.
> поэтому tcp over tcp работает плохо - а tcp over udp прямо идеально агаНамного лучше. В tcp over tcp - таймауты вложенных соединений не дружат с таймаутами внешних. И вообще TCP крайне паршиво и диалапно реагирует на малейшие проблемы, типа выпадения пакетов или повышения RTT в беспроводной сети. Такое комбо склонно к коллапсу при первых намеках на проблемы, обваливаясь до воистину диалапных скоростей. Немного лечится, но - только под линуксом и даже после плясок - это полумеры и компромиссный результат.
UDP этим не страдает - в нем нет понятия таймаутов на уровне протокола. Поэтому он новых проблем для вложенных TCP соединений не создает.
> Более быстрая реализация алгоритма вполне может оказаться не безопасной. Аудит проводили? Кто? На чьи деньги? Где отчет?Проводили, отчет в сети, ты просто не умеешь гуглить.
> И почему вдруг VPN не должен уметь TCP? Есть несколько сценариев, в которых использование TCP принципиально. Например неадекватный провайдер, низкое качество канала или обход через прокси.
В чем принципиальность использования TCP, если даже HTTP/3 (который по UDP) в таких условия работает лучше обычного HTTP (который по TCP)?
> Они несколько лет пропихивали изменения в двух подсистемах одним проектом? Они серьёзно думали, что получится? Так не делается - один проект пилит CryptoAPI, а второй пилит VPN. Только так. Аргумент "мы запили свою реализацию CryptoAPI, потому, что наш VPN с ней работает быстрее" как минимум не состоятельный. Тут может работать только такой "мы запилили VPN но он работает медленно, давайте перепилим CryptoAPI".
Они запилили, потому что API в ядре -- шит. Это часто случается с API в ядре. В итоге, разработчики API в ядре признали проблемы и начали запиливать Zinc в ядро.
> Странная движуха, слишком агрессивная.
Никаким другим образом пропихнуть улучшения в ядро нельзя.
Подскажите простому генту-юзеру, с целью повышения уровня образованности. Насколько сложнее по сравнению с OpenVPN конфигурировать сабжа на OpenWRT-роутерах? (Сейчас используется схема, где к серверу OpenVPN подключается клиент + доступ из сети сервера в сеть за клиентом).
Есть статья https://overclockers.ru/blog/Indigo81/show/30877/wireguard-o...
Возможно, это не оригинал.
Сам юзаю скрипт https://github.com/trailofbits/algo для разворачивания на микроинстансах, что к вашему вопросу не имеет отношения, но вдруг кому-то пригодится.
https://openwrt.org/docs/guide-user/services/vpn/wireguard/b...
в основном конфига даже проще, но когда захочешь вывести из тунеля запросы к оппределённым подсетям придётся уже повозиться с конфигом немногоибо удобных гуей как для опенвпн пока нету, как и кучи гайдов на все частные случаи болезни.
> в основном конфига даже проще, но когда захочешь вывести из тунеля запросы к оппределённым подсетям придётся уже повозиться с конфигом немногоибо удобных гуей как для опенвпн пока нету, как и кучи гайдов на все частные случаи болезни.WG не пытается быть слишком умным, и все эти вопросы решаются тупо роутингом.
openvpn тоже сам ничего не роутит, просто добавляет маршруты.
осталось рассказать каким роутингом.
> openvpn тоже сам ничего не роутит, просто добавляет маршруты.А я то думал что он сперва должен пакеты из tun или tap прочитать, понять что с ними сделать, зашифровать, и вот тогда ... он сможет отдать это ядру. Роутит, конечно, ядро, но толку с этого при таком раскладе довольно немного.
Чтение в/из сокета не является маршрутизацией. И никак к ней не относится. Ваш Кэп.
> Чтение в/из сокета не является маршрутизацией. И никак к ней не относится. Ваш Кэп.Да просто openvpn должен довольно много всего сделать на своей стороне. В процессе несколько раз отфутболив пакеты в ядро и получив их из ядра. А вот это довольно затратно.
> создатели WireGuard в сентябре приняли компромиссное решение перевести свои патчи на использование имеющегося в ядре Crypto API, к которому у разработчиков WireGuard имеются претензии в области производительности и общей безопасности.Ох ах, претензии к безопасности крыпто-АПИ ОС разрабатываемой в юрисдикции США и подлежащей экспорту.
Эх, а в моем стабильном дебиане wireguard появится только через пол года. Пока буду пользоваться по старинке openvpn-ом.
> Эх, а в моем стабильном дебиане wireguard появится только через пол года.ну чего ты хотел - супергерой по прежнему защищает человечество от нового софта - правда, постарел, захирел, супергеройской силы хватает только на пол-года.
Жди ебилдов - самому-то собрать из исходника, я так понимаю, неподъемная задача?
>> Жди ебилдов - самому-то собрать из исходника, я так понимаю, неподъемная задача?Мне есть куда тратить время, давно уже не студент.
Да вы нашли друга.
паняааатен... скажи, шибкозанятой нестудент - нах ты вообще полез в этот открытый софт? Страдать что опять ебилда ждать приходится?Тебе ж от него нет даже той ограниченной пользы, которая в нем еще осталась - а между тем, в Б-жественной Десяточке - все уже год работает из коробки.
P.S. пересобрать пакет из уже готового исходника лично у меня займет пару минут. Можно сэкономить, побыстрее прожевав бутерброд. Но ты ж просто не умеешь, давно-уже-не-студент, забывший научиться элементарным вещам.
> P.S. пересобрать пакет из уже готового исходника лично у меня займет пару
> минут. Можно сэкономить, побыстрее прожевав бутерброд. Но ты ж просто не
> умеешь, давно-уже-не-студент, забывший научиться элементарным вещам.Хотел бы посмотреть как ты за пару минут пересоберешь за нескольких десятках машинах с разными архитектурами процессоров разные линуксовые дистрибутивы с разным набором пакетов. А потом еще и заплатишь со своего кармана за протраченное время машинами CPU на компиляцию этих самых пакетов.
> Хотел бы посмотреть как ты за пару минут пересоберешь за нескольких десятках машинах с разными
> архитектурами процессоровкокой ужос.
А на практике у тебя один ноут, и тот с битым экраном, да? До этого ты звездел что у тебя, бедняжечки, "времени нет". Теперь, оказывается, у тебя десятки машин с разными (десятки, ага) архитектурами, ну надо же ж.
> А потом еще и заплатишь со своего кармана за протраченное время машинами CPU на компиляцию этих
> самых пакетов.малыш, не звезди - там где вообще хоть как-то считается "время CPU" в пересчете на деньги и его хоть как-то можно в микроскоп разглядеть - там архитектура одна и та же - amd64. И собрать можешь на своем битом ноуте - если бы, конечно, у тебя на самом деле была такая необходимость. И умения, что немаловажно.
А время CPU ржавого хлама - ничего не стоит. Он кроме тебя никому и не нужен.
Жди ебилдов - это явно единственное, что ты умеешь. Помимо сказаний о суперзанятости и десятках архитектур.
Даже самому обычному человеку сейчас нужно:
1. Виртуалка для разработки: сервер висит с облаке, где-то в хетцнере.
1. Один рабочий ноут, всегда включен, лежит в офисе, минимум софта.
Даже самому обычному человеку сейчас нужно:
1. Виртуалка для разработки: сервер висит с облаке, где-то в хетцнере.
1. Один рабочий ноут, всегда включен, лежит в офисе, минимум софта.
на рабочем ноуте 1 виртуалка для инета.
1 виртуалка с проприетарным софтом и браузером для коммуникаций с коллегами по работе.
> Даже самому обычному человекуя так и думал - альтернативно-одаренный разработчик-аутсорсер, зарабатывает в поте лица (сдавая квартиру, оставшуюся от бабушки)
У обычного человека занимающегося разработкой - сервер не где-то в облаке, а вон - в корпоративном ЦОД (и не один, да - но их конфигурация отнюдь не напоминает кунсткамеру). И там ни разу не нужны васян-поделки, там нормальный stonesoft стоит.
Ну ок, предположим нищая лавчонка сэкономила на всем - сервера "где-то в облаке", в офисе срач и помойка, посреди помойки чудо-ноут. А миллион архитектур откуда взялся? В хетзнере архитектура тоже одна-единственная, опять amd64. И если специально срач не разводить - то и версия дебиана на всех будет одна и та же. Пакет надо собрать - один раз. Вы "фуллшмяк девелопер", и умеете только вебню, так ведь?> 1 виртуалка с проприетарным софтом и браузером для коммуникаций с коллегами по работе.
и на ней - винда. Угу. А причем тут страдания с зоопарком клиентов, которым до смерти нужен wg ?
Даже самому обычному человеку, вроде меня для комфортного существования нужна:
1 Виртуалка для разработки: сервер висит с облаке, где-то в хетцнере.
2 Один рабочий ноут, всегда включен, находится в офисе, минимум софта.(dwm, suckless-tools, ...)
на рабочем ноуте 3. виртуалка для инета.
4. виртуалка с проприетарным софтом и браузером для коммуникаций с коллегами по работе.
5. виртуалка с проприетарными дровами для разных принтеров.
+~1-5 виртуалок с разными с разными пакетами программ, компилятор для разработки части софта локально.10. Виртуалка лежит где-то в azure с openvpn сервером для создания сети между тел. рабочим ноутом, виртуалкой для разработки и домашним ноутом.
11. Виртуалка лежит где-то в azure c openvpn сервером для создания сети между домашними устройствами.
12. Домашний ноут.
11. Виртуалка для работы с нетом. (браузеры).
12. Виртуалка для работы с media(gimp, pcmanfm, freecad)
13. Виртуалка для работы с платежами(браузер)
14. Виртуалка для работы
+5-10 Виртуалка для разработки, тестирования разного рода софта25. Домашний роутер.
26. Android TV box для TV.
27. Bearglboard для управления IP камерами.
28. Внезапно телефон (android).29. Виртуалка со скриптом для стягивания музыки из инета по тегам last.fm и бродкастига через icecast(что бы всегда слушать музыку без рекламы.). лежит где-то на серверах azure.
30. Виртуалка для выхода в tor сеть. лежит где-то на серверах azure. (ибо не из каждого офиса можно выходить в tor)
--
И это еще не учитывая виртуалок/докеров которые приходится время от времени поднимать/настраивать в офисе: для сборки приложений/тестирования.
И не учитывая роутеров/пек у родственников. которые тоже нужно иногда админить.
--И все эти устройства надо как-то связывать между собой, что бы было удобно до них достучаться с рабочего ноута/домашнего ноута/телефона.
[skip прекрасный зоопарк - теперь понятно, почему у владельца нет времени разобраться, как же ж это в дебиане пересобрать примитивный пакетик. Зато нашлось время героически заводить виртуалку на каждый чих и с каждой сооружать vpn-линк - отдельный]> И все эти устройства надо как-то связывать между собой, что бы было удобно до них достучаться с
> рабочего ноута/домашнего ноута/телефона.банальный ssh, стесняюсь спросить, отменили?
> банальный ssh, стесняюсь спросить, отменили?vpn из ssh таки довольно паршивый.
>> банальный ssh, стесняюсь спросить, отменили?
> vpn из ssh таки довольно паршивый.почему?
> почему?Ну, блин, ppp в VPN в XXI веке - это таки лол.
>> банальный ssh, стесняюсь спросить, отменили?
> vpn из ssh таки довольно паршивый.там не нужен на самом деле vpn - половина этих чудес в одной сети, другой половине не надо между собой общаться - так что связка "всех со всеми" лишняя, и только позволяет первому залетевшему дятлу поиметь всю сеть.
А для удаленного доступа ssh справится и без оберток.
> дятлу поиметь всю сеть.В случае вайргада дятл имеет ровно столько сколько ему прописано в конфиг. И там это довольно красиво сделано - привязка ключей шифрования к адресам или диапазонам. На самом деле это гениально по своей простоте, эстетичности и результативности. Даже если и оскорбляет взор маститых айписеков.
> А для удаленного доступа ssh справится и без оберток.
Очень зависит от того доступ к чему подразумевается. SSH хорош для управления вон тем компьютером. И только.
>> дятлу поиметь всю сеть.
> В случае вайргада дятл имеет ровно столько сколько ему прописано в конфиг.еще и все, до чего дотянется через туннель.
> И там это довольно красиво сделано - привязка ключей шифрования к
> адресам или диапазонам. На самом деле это гениально по своей простоте,
> эстетичности и результативности. Даже если и оскорбляет взор маститых айписеков.sa тоже привязывается к адресам - правда, нормальными масками, а не "диапазонами" - еще ж инженеры проектировали, им это не казалось трудно. И вплоть до портов.
>> А для удаленного доступа ssh справится и без оберток.
> Очень зависит от того доступ к чему подразумевается. SSH хорош для управления
> вон тем компьютером. И только.ssh хорош для всего, для чего годится шелл. Причем шелл, в котором есть икс-сокет (ах, ну да, ну да - новые ж стандарты не умеют. Ну значит ssh вычеркиваем, подставляем rdp)
С вон того компьютера очень много чем можно поуправлять. Настолько, что иногда приходится намеренно изолировать.
Легко ставится через pinning соответствующих пакетов из unstable.
https://www.wireguard.com/install/#debian-module-tools
Рекомендую сначала самому проверить, прежде чем писать бред. Если следовать инструкциям из wireguard, то в debian buster с пакетом wireguard из unstable ветки, внезапно, при запуске вывалиться с ошибками, ибо ядро debian buster имеет "устаревшее" ядро, и что бы запустить wireguard надо апдейтить само ядро до версии на которую завязан wireguard, а не просто скачивать бинарник с либами.
https://blog.veloc1ty.de/2019/11/28/wireguard-arch-error-unk.../
> https://blog.veloc1ty.de/2019/11/28/wireguard-arch-error-unk.../тредстартер страдал по штабильному дебиану. Сборка для которого делается за несколько минут. Причем тут - ракопроблемы? У них рач головного мозга, им простительно.
https://www.opennet.dev/openforum/vsluhforumID3/119190.html#197
> Эх, а в моем стабильном дебиане wireguard появится только через пол года.Ну как бы во первых бэкпорты, во вторых, make deb-pkg не очень сложно в консоли напечатать. Да, ядро умеет собирать себя в deb-пакеты.
но ведь ядро линукс официально является гибридным и никакой философии модульности или монолитности противоречить не может потому что соответствует им обоим одновременно.
телеметрия будет работать быстрее если её добавить в ядро
> телеметрия будет работать быстрее если её добавить в ядроПока что самая большая сеть слива телеметрии — Tor Project (by NSA). Пока в ядро не интегрировали.
OK, но при чём тут wireguard?
Ну как бы с 2.4 openvpn может в AES-GCM
И что это меняет?
типа на модных процессорах должен быть побыстрее.
Правда, для большинства васянов его скорость банально равна скорости их двадцатимегабитного интернета, но они ж начитались писулек и насмотрелись графичков...
> типа на модных процессорах должен быть побыстрее.Типа а потом мы запустим это на роутере или одноплатнике, потому что держать всегда включеным здоровенный шумный агрегат ломливо - и обнаружим что производительность openvpn - "не очень". Если кто не вдуплил, wireguard просто нарасхват у юзеров openwrt, его там вкостылили вперед батек из майнлайна, слишком уж спрос велик.
>> типа на модных процессорах должен быть побыстрее.
> Типа а потом мы запустим это на роутере или одноплатнике, потому чтоповторяю для непонявших: проблемы с openvpn начинаются там, где кончается ваш роутер-одноплатник, и начинаются взрослые системы - где хаб одновременно обслуживает сотни подключений.
И да, на тысячи я не делал, а с сотнями- вполне справляется, упираясь в полосу пропускания линка.А "роутер" в этих местах - "здоровенный шумный агрегат". Юнитов шесть в стойке занимает, в отличие от лезвия на котором умещается весь впн-хаб.
> производительность openvpn - "не очень". Если кто не вдуплил, wireguard просто
> нарасхват у юзеров openwrt, его там вкостылили вперед батек из майнлайна,ну так они и должны страдать. Судя по "пятибаксовым виртуалкам" это все тот же контингент что торопользователи и прочие борцуны с режимом, им не для работы же ж.
А так - на первой rpi клиенты опять же упирались в канал (понятен, там где приходится костылить подобную хрень, канал ни разу не гигабитный и еще и с потерями). Без всякого aes-gcm.
Проблемы перфоманса - везде. Если что-то хорошо работает для пары хомяков на мыльнице, будет хорошо работать на большом сервере для сотен народа. Потому что пропорционально больше ресурсов, например, самое лобовое масштабирование.Если кто сомневается - смотрит историю accel-pptp или как его там. Там было 2 вида заинтересованных - "провы" и "мыльницы". Тут это соотношение вероятно похоже.
> им не для работы же ж.
Работа - это прикованный к веслу раб чтоли? Ему тоже впн ни к чему. А так сейчас толпа стартапов и удаленок, а вот страдать они не хотят.
> А так - на первой rpi клиенты опять же упирались в канал
На типовой мипсовой мыльнице например openvpn упрется явно не в канал - у этих и гигабит бывает, а вот вычислительной мощности - где как. А rpi как сетевая железка на роли гейтвея все же не совсем сподручна.
> Ну как бы с 2.4 openvpn может в AES-GCMОн не может в маленький, аккуратный и комапактный код, а также в секурные настройки без 9000 мест в которых можно облажаться. И очередная фича там - не "ура!" а "караул!" потому что увеличивает attack surface сетевой программы.
кокой ужос!
Покажите пальцем - где вы там сумели облажаться в десятке строк конфига, эквивалентных тому незамысловатому сервису, что предоставляет вайргад?> потому что увеличивает attack surface сетевой программы.
вы уже взломали какой-нибудь хороший и быстрый коммерческий vpn-сервис? (_все_, именно _все_ - предоставляют именно openvpn)
Поделитесь доступом, а то платить двадцатку в месяц накладно.
> Покажите пальцем - где вы там сумели облажаться в десятке строк конфига,Вы сами же и подсказали - а вон где с сертификатами. Дефолты openvpn в этом вопросе зачем-то дырявы. И похрен какой там AES, вообще не в этом проблема.
>> Покажите пальцем - где вы там сумели облажаться в десятке строк конфига,
> Вы сами же и подсказали - а вон где с сертификатами. Дефолтыну а там где? По сути все те же асимметричные ключи, только в обертке для альтернативно-одаренных.
> openvpn в этом вопросе зачем-то дырявы.э... а можно конкретнее? Или это опять сказки для самых маленьких об ужасных нисисюрных-нисисюрных алгоритмах шифрования?
Тогда не надо. Это скучно и глупо. К тому же авторы openssl о вас уже так позаботились, что от их заботы и дышать сложно стало.
> Или это опять сказки для самых маленьких об ужасных нисисюрных-нисисюрных алгоритмах шифрования?Оно по дефолту тип сертификата и прочие глупости не проверяет. Приколись, клиентский серт выдан правильным CA, все такое! Остальные клиенты этому CA верят. С точки зрения крипто если какой-то клиент решит изобразить сервер - получится.
Нет-нет, можно RTFMнуть, включить проверку типа сертификата и даже вроде иных полей, такой финт ушами отвалится, конечно. Но это ж надо разбираться и знать что так можно было, и вообще, мыслить как безопасник. Сколько админов делают именно это, именно так... :)
> Оно по дефолту тип сертификата и прочие глупости не проверяет.ну как бы предполагается, что если у тебя кто-то может подменить сервер, да еще и чисто случайно у него откуда-то взялся полноценный серт - ты настолько в глубокой оппе, что можно уже не париться мелочами.
Хотя ручка в принципе и предусмотрена, корявенькая (в конце-концов, это v3 ext, как и все прочее - в те времена, когда эту хрень писали, v3 еще не было)А наиболее простой и, казалось бы, очевидный способ - просто использовать разные CA для сервера и для клиентов - они ж никак не связаны, клиент сам себя не проверяет, да и наоборот тоже.
> Сколько админов делают именно это, именно так... :)
и их юзеру совершенно ничего не грозит. Куда более вероятно что они проимеют ключ CA, валяющийся на десктопчике админчика или вовсе прямо на сервере (который по совместительству корпоративный вебсайт, почта и вебмин для управления всем сразу).
> ну как бы предполагается, что если у тебя кто-то может подменить сервер,Для себя я буду предполагать что я не хочу разминировать инструментарий до того как пользоваться им. Чем меньше телодвижений такого плана - тем лучше для меня инструмент.
> да еще и чисто случайно у него откуда-то взялся полноценный серт
Чисто случайно, клиентские сертификаты - достаточно полноценны для этого. Еще более случайно, некоторые реализации опенвпн-а не хотят работать если клиенту в подобной конфигурации сертификат не дать. В целом по планете это сколлапсировало в вот такую ситуацию: много конфигураций где сертификаты "пришлось выдать" (иначе саппортам все время делают мозг) - а защитой от этого самого не озаботились.
> - ты настолько в глубокой оппе, что можно уже не париться мелочами.А с вайргадом те же господа в именно такую оппу все-таки не попадут. Это просто не предусмотрено.
> Хотя ручка в принципе и предусмотрена, корявенькая
Оно предусмотрено, но почему-то везде где меня волновало - это вообще самому приходилось дописывать. Админам делавшим .ovpn файлы на раздачу секурити клиентов была почему-то до балды. Ну и смысл в шифровании и проч, если любой клиент потом под сервер сможет косить? Чтобы пару раз в месяц CVE в огромной мегалибе openssl-я затыкать? Без этого типа скучно? :)
> А наиболее простой и, казалось бы, очевидный способ - просто использовать разные
> CA для сервера и для клиентов - они ж никак не связаны, клиент сам себя не проверяет,
> да и наоборот тоже.Ну вообще-то первое что всем приходит в голову это слепить CA, выписать сертификат серверу и клиентам. И это в принципе даже катит, но проверку типа сертификата при хэндшейке почему-то надо явно впихивать в конфиг. По дефолту не делается.
> и их юзеру совершенно ничего не грозит. Куда более вероятно что они
> проимеют ключ CA, валяющийся на десктопчике админчикаДо десктопчика админчика еще добраться надо, неудобно. А клиентовый серт - у каждого первого клиента впн обычно есть. Его намного проще получить и его достаточно чтобы сервер изобразить. После чего ключ CA атакующему просто ни к чему.
> или вовсе прямо на сервере (который по совместительству корпоративный вебсайт,
> почта и вебмин для управления всем сразу).Это отдельная проблема, ортогональная озвученной.
Я не понимаю как еще понятнее объяснить: я видел толпу уязвимых конфигураций openvpn в диком виде. И это - не фича.
> Я не понимаю как еще понятнее объяснить: я видел толпу уязвимых конфигураций
> openvpn в диком виде. И это - не фича.ну блин. не сэкономить мне двадцать баксофф... ловить этих клиентов с их неправильными конфигурациями в переходе и отжимать ноуты - дело явно тухлое.
> ну блин. не сэкономить мне двадцать баксофф... ловить этих клиентов с их
> неправильными конфигурациями в переходе и отжимать ноуты - дело явно тухлое.Единственное чего я в той истории не понял - чего разработчикам мешало В КОДЕ сделать дефолты такими что тип серта проверяется, а если кому это мешает - вот тогда пусть и отключает из конфига или где там еще.
Это либо общий уровень дилетантизма в секурити и крипто, либо заморочки совместимости с какой-то окаменелой версией, либо пофигизм к юзкейсам. Вероятно, какая-то смесь этого. Ну и вообще, на TLS в силу его сложности довольно много дурных атак, типа даунгрейдов версий и шифров. На вайргада этот класс атак просто не работает - он так просто не умеет.
> Оно по дефолту тип сертификата и прочие глупости не проверяет. Приколись, клиентскийкстати, глянул - проверяет - по дефолту: https://github.com/OpenVPN/openvpn/blob/master/sample/sample...
правда, на самом деле оно так херню проверяет, но если не выпендриваться и делать как написано - сработает.remote-cert-tls server
но большинству и эта проверка - излишняя.
Как еще понятнее объяснить что в результате на практике половина конфиг - дырявы? К тому же некоторые странные ovpn клиенты почему-то хотят в такой конфигурации именно полноценный сертификат, с приватным ключом и проч. И только так. Без этого они просто не работают. Сапортам энтерпрайзов и продавцов впнов греют мозг - и приходится делать вот так. А про проверку все благополучно забывают, да и кому тот референсный конфиг надо?
Ну с чего им быть дырявым, если все копипастят именно этот образец?> да и кому тот референсный конфиг надо?
чо - самому что ли писать, с нуля? Ты еще скажи, что индус вообще знает, что туда написать-то. Теи более что ни синтаксис, ни семантика ни разу не являются простыми и очевидными.
сертификат (или вовсе chain) там и должен быть полноценный, как еще-то? Приватный ключ в нем при этом - не нужен, юзверь все равно от него пароль не знает, и вводить его некуда. Нужен только ключ от юзерского сертификата.
> Ну с чего им быть дырявым, если все копипастят именно этот образец?Видимо все-таки не этот - потому что вот это вот приходилось самому вписывать в случаях когда конфиг выдавали другие. Я не знаю как так у них получается, но эффект имеет место быть.
> чо - самому что ли писать, с нуля? Ты еще скажи, что
> индус вообще знает, что туда написать-то.Немного знать приходится. Потому что иначе или нифига не работает или саппорт на ушах стоит. А под именно openvpn появилось к тому же несколько странных полусовместимых реализаций, умеющих не все фичи (e.g. микротики) или очень странное понимание как и что должно работать (кто-то из клиентов зачем-то требует клиентский серт с валидным привкеем с ножом к горлу если уж используется PKI - и просто не работает если не дать ему это, на радость саапортам).
> Теи более что ни синтаксис, ни семантика ни разу не являются простыми и очевидными.
Да обычный там синтаксис, по сути то же что в командлайне, только в конфиге.
> сертификат (или вовсе chain) там и должен быть полноценный, как еще-то? Приватный
> ключ в нем при этом - не нужен, юзверь все равно от него пароль не знает,Некоторые клиенты хотят сертификат _клиента_ и непременно с приватным ключом (от этого серта) - иначе не работает. Саппорты встают на уши. Это маки, чтоли, так прикалываются с встроенной реализацией, или типа того. Ну и вот это вот безобразие - вполне катит как "сертификат сервера" если в конфиг проверку не вписать.
А общая ситуация с таким сочетанием свойств приводит к тому что почему-то дофига небезопасных конфигураций в диком виде. SSL/TLS и PKI довольно сложны для понмиания и секурно их использовать умеют единицы.
> и вводить его некуда. Нужен только ключ от юзерского сертификата.
Конечно. Так этот сертификат без упомянутой проверки и катит за серверный. Ключ от него есть, проверку типа серта почему-то часто не прописывают. Я не знаю, может это какие-то тулзы или скрипты индусам генерят, или типа того. Но факты штука упрямая.
один фиг на где-то 50 мегабитах затык на пятибаксовой виртуалке. С WG моя сотка проседает минимально. (С l2tp+ipsec, впрочем, тоже).
А без модуля ядра оно что, вообще не работает? Как-то это... А если я захочу поднять это на виртуальном хостинге?
> если я захочу поднять это на виртуальном хостинге?Навалом хостингов продающих виртуалки по 1-2$/mo. Хоть что загружай, на что ресурсов хватит. А на каком-нибудь openvz и прочее ты и так можешь обломаться - на загрузит тебе хостер модуль tun - и ты пойдешь нафиг.
> Навалом хостингов продающих виртуалки по 1-2$/mo. Хоть что загружай, на что ресурсов хватит.В смысле, разве в виртуалке за $1-2 можно загрузить свой ядерный модуль wireguard? Хотелось бы ссылочку на такую виртуалку.
