Состоялся (https://lists.cypherpunks.ru/pipermail/govpn-devel/2015-May/... релиз свободного VPN-демона
GoVPN 3.0 (http://www.cypherpunks.ru/govpn/), предназначенного для создания шифрованных аутентифицированных каналов связи поверх UDP. Реализация ориентирована на высокую безопасность и простоту реализации. Программа полностью написана на языке Go и распространяется (https://github.com/stargrave/govpn) под лицензией GPLv3. Поддерживается работа в GNU/Linux и FreeBSD.Для аутентификации участников соединения используется аутентифицируемый по парольным фразам протокол обмена ключами DH-A-EKE (Diffie-Hellman Augmented Encrypted Key Exchange), устойчивый к атакам по подбору паролей по словарю. При компрометации БД сервера DH-A-EKE всё-равно не позволит представиться клиентом, не зная целого пароля. Также имеется защита от атак повторного воспроизведения (http://en.wikipedia.org/wiki/Replay_attack), дешифровки сохранённого трафика даже при компрометации парольной фразы. Кроме обеспечения конфиденциальности есть возможность скрывать как размер сообщений, так и время их возникновения, путём генерирования постоянного шумового трафика.
Среди новшеств третей версии, по-сравнению со второй (http://www.opennet.dev/opennews/art.shtml?num=41833), можно отметить:
- Сообщения согласования канала связи стали неотличимы от шума (так же как и транспортные);
- Злоумышленник имеет меньше шансов заставлять сервер потреблять энтропию; появилась real-time статистика соединений;
- Конфигурация задаётся для каждого клиента отдельно, а не глобально;
- Возможность скрытия размера сообщений, за счёт добавления шума;
- Возможность скрытия времени возникновения пакетов, за счёт константного по-скорости трафика;
- EKE-протокол заменён на Augmented-EKE, который предотвращает возможность представиться клиентом даже при компрометации базы данных сервера, так как он хранит не общий ключ, а только verifier (проверяльщик) от него.URL: https://lists.cypherpunks.ru/pipermail/govpn-devel/2015-May/...
Новость: http://www.opennet.dev/opennews/art.shtml?num=42155
Кто то трогал это уже ручками?
Лучше палочкой.
По идее, оно вообще не должно работать - написано, что безопасный же.
Я собрал, запустил между двумя виртуалками, поигрался, полет нормальный. Единственное что, не удобно все собирать руками, по причине отсутствия вменяемой документации, в остальном все норм.
А можете сказать что не хватает, чего стоит доработать в документации?
Вот было бы оно на каком то другом языке, можно было бы посмотреть, а так оно само себя назвало безопасным
Шикарно, в циаты суну!
А с девками не пробовал?
Здесь таких нет.
> Вот было бы оно на каком то другом языке, можно было бы
> посмотреть, а так оно само себя назвало безопаснымОно написано на лучшем языГе для такого . Так что инна.
Звучит интересно, но самому пощупать времени нет, а обзоров тоже пока не вышло. Я так понимаю, демон работает по своему протоколу, в котором реализованы алгоритмы, которые автор счёл "годными". Например, в качестве алгоритма шифрования данных прибит гвоздями Salsa20. Имхо - не очень верно с точки зрения перспективы, нет гарантии, что через год-два-три какой-нибудь Куртуа не найдёт в алгоритме уязвимость (пусть даже и умозрительную).
> прибит гвоздями Salsa20. Имхо - не очень верно с точки
> зрения перспективы, нет гарантии, что через год-два-три какой-нибудь Куртуа не найдёт
> в алгоритме уязвимость (пусть даже и умозрительную).Salsa20 уже более 10 лет существует и имеет множество криптоанализов. А заменить его на что-то другое: в общем-то поменять строчек пять кода наверное. До сих пор нет доказательств что ECC безопасность полностью зависит от проблемы на которой основана, но ECC используют даже спецслужбы уже.
Решение проблемы сервера за провайдерским NAT-от, вот что заставит оторваться от OpenVPN.
И как к нему обращаться? По какому адресу?
STUN, NAT-PMP
DDNS или передача проброшенного порта (внешних IP:порт), например, через публичный сервер XMPP.
PMP это только, грубо говоря, для домашних условий. Если дома NAT мешает жить, то надо исправлять именно эту проблему, а не пытаться её обходить костылями. Надо активнее начинать использовать и подталкивать провайдеров к IPv6, а не мириться с неработающим Интернетом (NAT фактически ломает его архитектуру) и пытаться жить в этих условиях. STUN это зависимость всё-равно от какого-то третьего лица. Уж лучше поднимать туннели до IPv6-брокеров или Teredo.
На хубре уже было.
Оно до 100 мегабит на одном ядре хеона вытягивает.
И я так понял не особо параллелится.Ядерная реализация или реализация на сях, без SSE/AVX оптимизации сальсы дала бы по полтора гигабита с ядра того же хеона.
Такие мелочи авторов не интересуют. Главное, что на гоу.
> Такие мелочи авторов не интересуют. Главное, что на гоу.В целом вы правы. Главное: простота кода, возможность чтения кода, соответственно малый размер кода. Если код портируемый, то один и тот же кусок кода работает под разными ОС, а не под каждую писать совершенно разный. Человечество продемонстрировало что сложность и C означают невозможность в течении уж 15 лет написать грамотную реализацию TLS. Либо N-месяцев разработки на Go, либо NN лет на C под разные ОС и это будет нечитабельно (много кода) и соответственно недоверяемо.
BSD, Linux как раз писали на сях много лет.
Видимо им нельзя доверять, ведь их долго писали и они не на Go.
Перепишите их на GO, покажите всем класс! :)Мы уже общались на эту тему на хубре.
Повторю: си это универсальный язык для всех ОС, с отличной портируемостью и производительностью.
Если хочется максимального распространения кода в разных ОС - то только си.Ваше мнение о том что си долго кодить и дыры получаются зачтено.
Моё личное мнение: GO это тормозно, громоздко (в памяти), нифига не переносимо (нельзя взять кусок кода и утащить в ядерный модуль любимой ОС).
В остальном, я бы написал на сях и не парился, кода там совсем мало, фобии к сям у меня нет.
Go, php, java, perl, python - они все хороши, но не для таких вот применений. Максимум на них обкатать протокол и переписать на си.
И вам я уже отвечал: вы не представляете трудозатрат. Никто не спорит что в идеале на C лучше, в теории, а ещё лучше по производительности будет на ассемблере. Либо оно будет пусть помедленнее (хотя лично мне 100 Mbps на современном процессоре -- за глаза) но написано и рабочее, либо это так и будут мечты и росскозни о том как бы было здорово написать подобное на C, но без результата и, даже если и написав, то долгое время требующего отладки и анализа, которые не дают результат годный для уверенного применения.И я уже говорил что вы до сих пор так и не поняли суть: цель это получить код который можно прочитать, проанализировать. Тонны кода на C никто читать не будет. Либо производительность, либо безопасность/гарантии/надёжность/спокойствее/неспешное, либо на порядки большие трудозатраты... ради того чтобы ускорить в несколько раз? На порядки большее время разработки для ускорения в разы? С экономической точки зрения опять же выходит проще купить железо, о чём вам и втолковываю. Стоимость разработки ПО в разы выше стоимости железа. Это просто факт. Если вы считаете что на C подобное надёжно переписать это всего ничего, то я уверен что у вас крайне мало опыта написания качественного надёжного *криптографического* ПО и поэтому вы даёте такие оценки. Если вы считаете что оно того стоит... ну бывают такие ситуации когда например на космическом аппарате стоимость железа всё же выше софта, бывает.
> И вам я уже отвечал: вы не представляете трудозатрат. Никто не спорит
> что в идеале на C лучше, в теории, а ещё лучше
> по производительности будет на ассемблере. Либо оно будет пусть помедленнее (хотя
> лично мне 100 Mbps на современном процессоре -- за глаза) но
> написано и рабочее, либо это так и будут мечты и росскозни
> о том как бы было здорово написать подобное на C, но
> без результата и, даже если и написав, то долгое время требующего
> отладки и анализа, которые не дают результат годный для уверенного применения.Это вы меня тролите чтобы я взял и переписал это в CVPN?
Си переносим, ассемблер - почти нет.В начале января я экспериментировал с ChaCha20 шифрованием дисков в ядре FreeBSD (geom_eli). Это не долго и кода не много.
>[оверквотинг удален]
> либо на порядки большие трудозатраты... ради того чтобы ускорить в несколько
> раз? На порядки большее время разработки для ускорения в разы? С
> экономической точки зрения опять же выходит проще купить железо, о чём
> вам и втолковываю. Стоимость разработки ПО в разы выше стоимости железа.
> Это просто факт. Если вы считаете что на C подобное надёжно
> переписать это всего ничего, то я уверен что у вас крайне
> мало опыта написания качественного надёжного *криптографического* ПО и поэтому вы даёте
> такие оценки. Если вы считаете что оно того стоит... ну бывают
> такие ситуации когда например на космическом аппарате стоимость железа всё же
> выше софта, бывает.Вообще то в 14 раз как минимум, без особых оптимизаций.
Если код не читают - значит он не нужен :)
На си почти всё под контролем (ну кроме кешей и совсем уж низкоуровневых вещей), в GO никаких гарантий что использованный ключ в памяти затрётся как и должен и не будет 100500 копий размазано сборщиком мусора по всей памяти.
С экономической точки зрения - я лично сниму все претензии к производительности если вы на свои деньги всем пользователям GoVPN будете апгрейдить железо до состояния когда они будут получать нужную им скорость и оплачивать электричество.
Ну может ещё молоко за вредность покупать, всё же шум и "излучения" :)
>Это вы меня тролите чтобы я взял и переписал это в CVPN?Я -- троллю?
>Си переносим, ассемблер - почти нет.
Особенно когда API разные C очень переносим.
>Если код не читают - значит он не нужен :)
То есть OpenSSL не нужен?
>На си почти всё под контролем (ну кроме кешей и совсем уж низкоуровневых вещей)
Ага, именно поэтому для AES есть атака которая позволит получить ключи шифрования из кэша.
>в GO никаких гарантий что использованный ключ в памяти затрётся как и должен и не будет 100500 копий размазано сборщиком мусора по всей памяти.
Никто вам не мешает на время жизни переменной её обнулить (явно записать нули) до того как она попадёт в сборщик. Ваш довод на пустом месте.
>всем пользователям GoVPN будете апгрейдить железо до состояния когда они
будут получать нужную им скорость
Вы единственный и первый пользователь которого не удовлетворила скорость.>Все эти языки - они не для того чтобы терабайты молотить, а чтобы быстро и просто
прототипировать и писать простые программы не думая о сложных вещах.
Опять же на пустом месте мнение.>Если вы не в курсе - там ещё и копирование данных есть, если всякие хаки не использовать.
Боюсь что в курсе даже абсолютных значений падений производительности при этом. Вы -- первый кого это стало так волновать. Другие гоняют десятки гигабит через userspace/TAP и не переживают за лишнюю сотню-две долларов при этом (учитывая стоимость остального железа для этого).
>Если это VNP концентратор то его единственная задача - гонять шифрованный трафик. Чем эффективнее он это делает тем лучше.
Какой у вас замечательный мир где вы просто берёте и шифруете. В моём мире шифрование ещё нужно правильно надёжно применить (не как реализовали протоколы в OpenSSL) и предотвратить различные атаки, для чего не совсем простое рукопожатие и используется. Во всех ваших комментариях я ни разу не видел упоминания безопасности. Ощущение что вам не нужно шифрование как таковое, только некая обфускация.
Ваш комментарий про то что надо наоборот всё засовывать в ядро, намёк на долой модульность, микроядро... даже комментировать всерьёз рука уже не поднимается. Опять же все мысли только о производительности, ни одной про безопасность.
А всё вышенаписанное особенно в начале говорит о том что вы явно начали нести откровенный бред который называется троллингом. Так что прекратим "дискуссию". Крайне печалит что в современном Интернете преобладающая часть людей скатывается до состояния этих вот так называемых троллей: куча ничем не подкреплённых на пустом месте взрощенных мнений.
>>Си переносим, ассемблер - почти нет.
> Особенно когда API разные C очень переносим.У меня вот прекрасно работают программы под фрёй и чуть хуже в линухе.
>>На си почти всё под контролем (ну кроме кешей и совсем уж низкоуровневых вещей)
> Ага, именно поэтому для AES есть атака которая позволит получить ключи шифрования
> из кэша.Там слишком много условий для реализации атаки.
В GO вообще не понятно что и как там под капотом работает на самом деле.
>>в GO никаких гарантий что использованный ключ в памяти затрётся как и должен и не будет 100500 копий размазано сборщиком мусора по всей памяти.
> Никто вам не мешает на время жизни переменной её обнулить (явно записать
> нули) до того как она попадёт в сборщик. Ваш довод на
> пустом месте.Где гарантии что оно не скопировало предварительно или не оптимизировало?
>>всем пользователям GoVPN будете апгрейдить железо до состояния когда они
> будут получать нужную им скорость
> Вы единственный и первый пользователь которого не удовлетворила скорость.А и не будет пользователей с такой прожорливостью.
>>Если вы не в курсе - там ещё и копирование данных есть, если всякие хаки не использовать.
> Боюсь что в курсе даже абсолютных значений падений производительности при этом. Вы
> -- первый кого это стало так волновать. Другие гоняют десятки гигабит
> через userspace/TAP и не переживают за лишнюю сотню-две долларов при этом
> (учитывая стоимость остального железа для этого).Да не гоняет никто в серьёзных применениях.
Вон NATd во фре, очень все любили, куча мануалов и хаутушек, но забросили использовать, ибо он юзерспейсный и в сравнении с ядерными ощутимо больше жрёт.
> Ваш комментарий про то что надо наоборот всё засовывать в ядро, намёк
> на долой модульность, микроядро... даже комментировать всерьёз рука уже не поднимается.
> Опять же все мысли только о производительности, ни одной про безопасность.Ну вот засовывают, в линуксах, фрях, и даже вендах. И никто в юзерспейс на пхп/бейсике не переписывает.
Модульность в ядрах давно есть.
> Крайне печалит что в современном Интернете преобладающая часть людей скатывается до
> состояния этих вот так называемых троллей: куча ничем не подкреплённых на
> пустом месте взрощенных мнений.Тормозит? - Да.
Ощутимо? - весьма: минимум 14 раз.
Можно было сделать лучше? - Да.
Почему нет? - по религиозным соображениям, не иначе.Ну не серьёзно же.
Вся крипта во всех референсах почти всегда си. Это же не просто так.
>У меня вот прекрасно работают программы под фрёй и чуть хуже в линухе.Одни и те же, ядерные? Ну это же враньё.
> GO вообще не понятно что и как там под капотом работает на самом деле.
А компилируя GCC C-шный код вы знаете что он сделает в итоге? Очевидно что нет. Go же кстати не шибко пытается производить оптимизации и посмотреть что он делает куда проще. Потому-что код -- простой. Не даром же им занимается Кен Томпсон.
>Где гарантии что оно не скопировало предварительно или не оптимизировало?
На C вам точно так же никто таких гарантий не даст. Только если переписать на ассемблере. И всё-равно Intel не даст гарантий что вы очистили везде всю память (кэш).
>А и не будет пользователей с такой прожорливостью.
Если пользователю нужна безопасность (A-EKE не вижу чтобы реализовали в TLS (хотя там есть SRP в GnuTLS) или SSH например, вообще не видно нигде) -- найдутся. Если вам важна скорость, то старый добрый RC4 и не дай бог использовать Диффи-Хельмана.
>Ну вот засовывают, в линуксах, фрях, и даже вендах.
Ну, а кто-то считает что Java и всё что не C годится только для прототипирования. То есть Ada для оборонки -- закрываем глаза, Lisp для космических аппаратов -- тоже, Java для бирж и банков... всё на прототипах работают, нигде нет конечной реализации, как же так.
>И никто в юзерспейс на пхп/бейсике не переписывает.
Лично я вижу что полно переписывают и выносят из ядер. FUSE видимо just-for-fun написали тоже.
>Модульность в ядрах давно есть.
А чтобы при этом был асинхронный переключатель контекста модулей внутри -- нет.
>Тормозит? - Да.
У вас возможно. У меня нет. Моя сеть нагружена на 100% и я не замечаю. Тормозит это когда ты видишь что что-то не так, где-то тормоза. Когда я включаю GoVPN и не вижу разницы... ответ очевиден.
>Ощутимо? - весьма: минимум 14 раз.
Цифра взята с потолка?
>Можно было сделать лучше? - Да.
>Почему нет? - по религиозным соображениям, не иначе.Ваш код на C можно сделать "лучше"? Да. Почему нет? Потому-что ассемблер это не C и годится только для прототипирования?
Снова поясню. Для вас, троллей, нет понятия времени. А для обычных людей оно есть и очень ценное. На C мало кто умеет релизовывать криптографию качественно (что писать, что читать). Например за всё время существования OpenSSL таких людей у них не нашлось. То есть 15 лет разработки и до сих пор небезопасный (читаем: неработающий (так как это криптография и оценки тут жёстче)). У меня несколько месяцев разработки и протокол безопаснее, работает. Ну да, конкретно для вас стоимость его использования увеличивается на стоимость одного ядра процессора. Поверьте, это на порядки дешевле чем стоило бы время разработчика.
>Вся крипта во всех референсах почти всегда си. Это же не просто так.
Потому-что просто криптоалгоритмы низкоуровневые (а не протоколы) это чисто математика которую надо записать в виде псевдокода. В данном случае псевдокод совпадает с C по простоте.
И... вы считаете что reference implementation это то что стоит использовать в бою? Ничего что очень часто я в них видел "вот тут вы должны сделать constant time сравнение"? Сами они не приводят такие штуки, так как они platform-specific как правило. Reference это то с чем можно сравнивать корректность результата работы, а не то что можно смело использовать в бою. Reference implementation какого-нибудь RSA как яркий пример.
>>У меня вот прекрасно работают программы под фрёй и чуть хуже в линухе.
> Одни и те же, ядерные? Ну это же враньё.Программы а не модули/драйвера.
>> GO вообще не понятно что и как там под капотом работает на самом деле.
> А компилируя GCC C-шный код вы знаете что он сделает в итоге?
> Очевидно что нет. Go же кстати не шибко пытается производить оптимизации
> и посмотреть что он делает куда проще. Потому-что код -- простой.
> Не даром же им занимается Кен Томпсон.С гцц/шлангом можно получить ассемблерный листинг или дизассемблировать обратно и убедится.
Чтобы посмотреть чем го занимается на самом деле нужно смотреть итоговый ассемблерный код, который, очевидно, будет куда дальше от исходников чем сишный.
>>Где гарантии что оно не скопировало предварительно или не оптимизировало?
> На C вам точно так же никто таких гарантий не даст. Только
> если переписать на ассемблере. И всё-равно Intel не даст гарантий что
> вы очистили везде всю память (кэш).На сях легко гарантировать и легко убедится.
Прочитать память легко, кеш - не реально.
>>И никто в юзерспейс на пхп/бейсике не переписывает.
> Лично я вижу что полно переписывают и выносят из ядер. FUSE видимо
> just-for-fun написали тоже.На время отладки - чтобы не валить ядро, либо потому что лицензия не совместима с тем что в ядре.
>>Ощутимо? - весьма: минимум 14 раз.
> Цифра взята с потолка?Е8500 на ChaCha20 блоками по 512 байт при шифровании и записи в tmpfs даёт примерно 1400 мегабит/сек, притом что там накладные расходы на запись ощутимы на фоне шифрования.
На хеоне и сетевом в/в в ядре скорость будет ещё больше.
Либо в юзерспейсе и с SSE/AVX сальсой, но на больших пакетах, на мелких - просядет из за больших накладных расходов на переключение, копирование, инициализации самой сальсы и прочих мелочей.
>>Можно было сделать лучше? - Да.
>>Почему нет? - по религиозным соображениям, не иначе.
> Ваш код на C можно сделать "лучше"? Да. Почему нет? Потому-что ассемблер
> это не C и годится только для прототипирования?Глупости.
Си современными копиляторами оптимизируется на уровне неплохих кодеров на асме.
И речь не про мой код.
> Снова поясню. Для вас, троллей, нет понятия времени. А для обычных людей
> оно есть и очень ценное. На C мало кто умеет релизовывать
> криптографию качественно (что писать, что читать). Например за всё время существования
> OpenSSL таких людей у них не нашлось. То есть 15 лет
> разработки и до сих пор небезопасный (читаем: неработающий (так как это
> криптография и оценки тут жёстче)). У меня несколько месяцев разработки и
> протокол безопаснее, работает. Ну да, конкретно для вас стоимость его использования
> увеличивается на стоимость одного ядра процессора. Поверьте, это на порядки дешевле
> чем стоило бы время разработчика.Ярлыки оставьте при себе.
За опенссл я бы не стал говорить.
Вашу реализацию вообще не тестили и аудит не проводили.
Перемножте время/деньги со всех инсталяций.
> Ваше мнение о том что си долго кодить и дыры получаются зачтено.Вы не так интерпретируете. На C можно кодить качественно. Вопрос трудозатрат. На ассемблере тоже можно. Вопрос трудозатрат. Зачем придумывают инструменты упрощающие жизнь разработчика? Чтобы вместо того что он тратил N человекочасов он смог потратить на 2-3 порядка меньше и получить результат пускай немного помедленнее, но если это приемлимо, то даже не обсуждается что этот инструмент хорош и выгоден. Нет никакого смысла затрачивать тьму времени, делая код который мало кто сможет проанализировать (в виду сложности анализа, так как нужно иметь много опыта чтобы с ходу увидеть например проверки выхождения массивов за границы и прочее) ради того чтобы ускорить его в несколько раз, при этом что запускаться оно будет на обычным современных железках, которые пока идёт разработка уже компенсируют производительность.
> Моё личное мнение: GO это тормозно, громоздко (в памяти), нифига не переносимо
> (нельзя взять кусок кода и утащить в ядерный модуль любимой ОС).Вы задавались вопросом почему тормозно или громоздко (кстати не обосновано)? Может потому-что он берёт управление памятью на себя? Потому-что там есть сборщик мусора? Да, это ресурсы, но которые экономят адское количество моего (разработчика) времени и избавляет от ещё большего количества возможных моих же ошибок. Я, как и преобладающее большинство, готовы платить за время процессора чтобы компенсировать своё и обезопасить от возможных ошибок. Именно поэтому появились высокоуровневые языки.
> Go, php, java, perl, python - они все хороши, но не для
> таких вот применений. Максимум на них обкатать протокол и переписать на
> си.Чем это обосновано? Особенно удивляет мешанина из динамически типизированных языков и интерпретируемых, с компиляторами и статической типизацией. Ваш мир делится на C и не C (ну ok, ассемблер ещё)? Задумайтесь для чего изобрели множество других языков. Не от нечего делать, поверьте, а от того что кода стали писать в тысячи раз больше чем когда появился язык C и люди начали делать какие-то выводы из своего опыта. Железо становится доступнее людям: когда-то компьютер это была роскошь как и автомобиль. Сейчас многие легко могут взять и докупить ПК/ноутбук/сервер. И хотят получить качественный результат, да поменьше тратя своё время разработчика.
>[оверквотинг удален]
>> си.
> Чем это обосновано? Особенно удивляет мешанина из динамически типизированных языков и интерпретируемых,
> с компиляторами и статической типизацией. Ваш мир делится на C и
> не C (ну ok, ассемблер ещё)? Задумайтесь для чего изобрели множество
> других языков. Не от нечего делать, поверьте, а от того что
> кода стали писать в тысячи раз больше чем когда появился язык
> C и люди начали делать какие-то выводы из своего опыта. Железо
> становится доступнее людям: когда-то компьютер это была роскошь как и автомобиль.
> Сейчас многие легко могут взять и докупить ПК/ноутбук/сервер. И хотят получить
> качественный результат, да поменьше тратя своё время разработчика.Все эти языки - они не для того чтобы терабайты молотить, а чтобы быстро и просто прототипировать и писать простые программы не думая о сложных вещах.
VPN это молотилка пакетов, а все эти языки на собственные нужды сожрут сильно больше чем основной алгоритм.
Про время-деньги - см пост выше.
> Моё личное мнение: GO это тормозно, громоздко (в памяти), нифига не переносимо
> (нельзя взять кусок кода и утащить в ядерный модуль любимой ОС).Более того. Зачем??? перетаскивать что-то в ядро? Очевидно я думаю что опять же хочется столь критичной (для вас) скорости из-за того что меньше дорогих (реально дорогих) переключений контекста программ в процессоре. Но если смотреть с точки зрения безопасности, то как-раз из ядра хочется вытаскивать как можно больше всего в userspace потому-что надёжнее, спокойнее, более изолировано, в случае краха не потянет за собой всё, в случае недобротного модуля/части ядра не будет скомпрометировано всё. Если вам надо решить проблему производительности, а мне безопасности -- то надо удешевить переключение контекста. Опять же вы готовы затратить кучу времени на написание сложной под-вопросом качества ядерной части, которая сильно ставит под вопрос безопасность системы, вместо того чтобы вынести в userspace, продвигать микроядерные ОС. В чём проблема? Наверное в том что Intel имеет крайне убогую архитектуру в которой контекст это очень дорого. В отличии от RISC систем где например тот же QNX не проседал на 50% из-за переключений контекста. Вам нужна скорость. Мне, моим целям -- безопасность. Userspace это бОльшая гарантия того что в случае краха оно не потянет за собой остальное. Плюс userpace это опять же портируемо: работаем с TAP как с файлом и радуемся, а не пишем с совершенно разным API куски кода ради экономии переключения контекста. Кстати любопытны абсолютные величины чего мы сэкономим. Результат я априори знаю будет такой что овчинка выделки не стоит чтобы даже задумываться о том чтобы тратить время на ядерную реализацию. Я много работал и с 10Gbps сетями в которых крутятся виртуальные машины через TAP-интерфейсы. Overhead есть, но такой что можно закрыть глаза.
>> Моё личное мнение: GO это тормозно, громоздко (в памяти), нифига не переносимо
>> (нельзя взять кусок кода и утащить в ядерный модуль любимой ОС).
> Более того. Зачем??? перетаскивать что-то в ядро? Очевидно я думаю что опять
> же хочется столь критичной (для вас) скорости из-за того что меньше
> дорогих (реально дорогих) переключений контекста программ в процессоре.Если вы не в курсе - там ещё и копирование данных есть, если всякие хаки не использовать.
Те эти 100 мегабит нужно два раза скопировать: в юзер спейс и обратно.
Но в случае с оверхэдом от GO это сущая ерунда :)
> Но если смотреть
> с точки зрения безопасности, то как-раз из ядра хочется вытаскивать как
> можно больше всего в userspace потому-что надёжнее, спокойнее, более изолировано, в
> случае краха не потянет за собой всё, в случае недобротного модуля/части
> ядра не будет скомпрометировано всё.Если это VNP концентратор то его единственная задача - гонять шифрованный трафик.
Чем эффективнее он это делает тем лучше.
Нет особой разницы, в данном случае, будет проблема в ядре или в приложении, ибо результат один - проникновение в VPN (чужих пакетов), в худшем случае.
> Если вам надо решить проблему производительности,
> а мне безопасности -- то надо удешевить переключение контекста. Опять же
> вы готовы затратить кучу времени на написание сложной под-вопросом качества ядерной
> части, которая сильно ставит под вопрос безопасность системы, вместо того чтобы
> вынести в userspace, продвигать микроядерные ОС. В чём проблема?В том, что код на GO.
В том, что у меня нет проблем с тем, чтобы запихать что то в ядро и убедится что оно не валится.
Те я вот в этом всём смысла не вижу совсем, какие то надуманные проблемы.
> Наверное в
> том что Intel имеет крайне убогую архитектуру в которой контекст это
> очень дорого. В отличии от RISC систем где например тот же
> QNX не проседал на 50% из-за переключений контекста. Вам нужна скорость.При работе в ядре тоже нет никаких проседаний.
Но виноват интел, потому что мы не хотим писать на сях и складывать это в ядерный модуль.
Очень удобная позиция.
> Мне, моим целям -- безопасность. Userspace это бОльшая гарантия того что
> в случае краха оно не потянет за собой остальное. Плюс userpace
> это опять же портируемо: работаем с TAP как с файлом и
> радуемся, а не пишем с совершенно разным API куски кода ради
> экономии переключения контекста. Кстати любопытны абсолютные величины чего мы сэкономим.У вас весь VPN - немногим больше хэлло ворда, большей частью состоящий из готовых криптопримитивов которые за вас уже отсмотрели, прочитали, проверили и заверили безопасность все кому только не лень.
Go только передаёт данные между ними, и делает это хреново.Выносить в ядро вообще всё смыла не имеет, имеет смысл в ядро утащить сальсу, место где оно подписывает сообщения, и тот кусок который за окно приёма отвечает.
Ассиметричную крипту и всё остальное что связано с рукопожатием в начале оставить в юзерспейсе, и там пофик на каком тормозном и безопасном языке оно будет написано, ибо основная работа будет в ядре.Примерно так и устроен mpd5 во фре, который жуёт гигабиты трафика от тысяч юзеров.
И accel-ppp (или как он там сейчас) тоже ядерный.
Кстати, ну просто для справки. С 3.1 версии оно стало почти в три раза быстрее. Треть процессорного времени отъедается для 100Mbps.
Чего-то в портах FreeBSD этого не вижу. Как оно распространяется? Блобом что ли?
> Чего-то в портах FreeBSD этого не вижу. Как оно распространяется? Блобом что ли?Авторов, ожидаемо, не интересуют маргинальные ОС.
Первый абзац новости говорит об обратном.
Если в портах чего-то нет, значит, это вы поленились сделать порт.
В чём проблема поставить ПО: wget, gpg -v, tar xf, make? Написание софта не подразумевает в обязательном порядке создание портов. Это требует время, много, проверок на качество. Времени может быть недостаточно у авторов.
> В чём проблема поставить ПО: wget, gpg -v, tar xf, make? Написание
> софта не подразумевает в обязательном порядке создание портов. Это требует время,
> много, проверок на качество. Времени может быть недостаточно у авторов.Необязательно.
Мантейнеров FreeBSD, значит, пока не заинтересовал сей концепт на Go.
Хм, то есть если интересное то обязательно будет в портах? Забавно.
> Чего-то в портах FreeBSD этого не вижу. Как оно распространяется? Блобом что
> ли?А перейти по ссылке на официальный сайт и увидеть самые обычные тарболлы?
Пока версталась новость вышла версия 3.1
Так оно что, покая я думаю, какую кнопку нажать, генерирует мне трафик? Намуя оно такое надо на моём "анлимитном" 3G от мегавони с ограничением до 64к после энных мегабайт.
> Так оно что, покая я думаю, какую кнопку нажать, генерирует мне трафик?
> Намуя оно такое надо на моём "анлимитном" 3G от мегавони с
> ограничением до 64к после энных мегабайт.Это опциональная возможность и она выключена по умолчанию. Если вам необходимо скрыть timestamp и размер пакетов, то других вариантов у вас в любом случае надёжных не будет.
Кажется, Саломаа говаривал в своей замечательной книге "прикладная криптография" - не шифруйте зашифрованное. Тем не менее, если есть что скрывать, найдётся куча способов реализовать педерачу драных.
Кажется, Саломаа говаривал в своей замечательной книге "прикладная криптография" - не шифруйте зашифрованное.
чет новенькое...
Саломаа ваш значит тупо гонит на стойкое шизокрипто, аэнбешник походу или аналогичный скам, ну то есть хуже таксиста короче..
А где клиент и сервис к нему?