Комментарии 52
Таким образом, я могу только предположить, что тест был выполнен с использованием еще более жирных фреймов с превышением размера в 64 килобайта с теоретическим максимумом в 1023 Мбит/с, что поддерживается только некоторыми сетевыми адаптерами. Но это абсолютно неприменимо в реальных условияхВ реальных условиях на сервере будет 10G интерфейс, и скорость будет ещё выше.
и OpenVPN предлагают функцию согласования шифров. Поэтому некоторое время, после которого вы включите новое шифрование, будет работать и старое. Благодаря этому текущие клиенты смогут обновиться до новой версии. После того, как обновление будет раскатано, вы просто выключите уязвимое шифрование. И все! Готово! вы восхитительны! А клиенты этого даже не заметят
Ахаха, нет.
У меня как раз недавно был кейс с OpenVPN (на OpenWRT роутере) где в древней версии было сжатие tls, а в новой версии его не было и обновив «сервер» — пришлось ехать к «клиенту» чтоб поправить конфиг, благо он был один и в том же городе.
Ахаха, нет.
У меня как раз недавно был кейс с OpenVPN (на OpenWRT роутере) где в древней версии было сжатие tls, а в новой версии его не было и обновив «сервер» — пришлось ехать к «клиенту» чтоб поправить конфиг, благо он был один и в том же городе.
Ахаха, да. Сорян за прямоту, но мне кажется, что вы OpenWRT-проблемы зачем-то в кучу в OpenVPN-проблемами смешали, и если поверх этого работает что-нибудь реально business-critical, то обновление OpenVPN — одна из наименьших ваших проблем.
Бизнес-критикала там нет, но процесс сложился: офису удобнее накладные печатать прямо на принтер производства чем высылать их емейлами, а производству удобнее забирать их с принтера, а не шуршать в почте и распечатывать.
Причем здесь OpenWRT, если это разработчики OpenVPN выкинули comp-lzo из 2.4?
При чем здесь OpenVPN, который comp-lzo не выкидывал? Пруф: community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-lzo
Опция --comp-lzo помечена как deprecated и «Currently not planned for removal», т.е. в OpenVPN она все еще есть, и все еще работает «for backward compatibility».
А то, что конкретно ваша сборка OpenVPN под конкретно вашу сборку OpenWRT на конкретно вашей железке — это именно OpenWRT-проблема. Поэтому я и говорю, не путайте OpenVPN-проблемы с OpenWRT-проблемами.
Бизнес-критикала там нет, но процесс сложился: ...
Ну это просто классическое «что-то к чему-то примотали скотчем, и оно теперь как-то работает». Странно эти проблемы адресовать к OpenVPN.
Но ведь от клиента не требовалась магия по поддержке чего-то нового, достаточно было не включать сжатие. Я почему возмутился — автор статьи нам рассказывает что OpenVPN сам по себе дико смышленый и сам все согласовывает, а по факту оказалось что нет, сообразить отключить сжатие он не может.
Может конечно имелось ввиду что настройки клиентам можно отдавать из ccd, но в статье это не указано явно.
Честно говоря весь параграф «Об игнорировании реальных проблем» больше похож на маркетинговый буллшит, какие-то абстрактные преимущества и недостатки без единого слова конкретики.
Ок, согласен, наверно OpenWRT сэкономили место и собрали без deprecated опций.
Ну, скорее подошла бы формулировка «немного через жопу». Не, не подумайте, это им не то чтобы в обиду. Просто природа самого проекта OpenWRT (и dd-wrt, до кучи) такова, что «немного через жопу» — это нормальное состояние. Задача «собрать некую штуку, которая будет работать на тысячах устройствах, которые не предназначены для запуска этой штуки в условиях отсутствия спецификаций на эти устройства» — она сама по себе достаточно ресурсоемка, нетривиальна и благородна, спору нет. И в какой-то определенной нише смысл от всех этих трудозатрат есть.
Просто сама постановка задачи предполагает, что работать это будет «как-то», «немного через жопу» и «ну ведь работает же». А условие «тысячи разных устройств без спецификаций» исключает а) возможность квалифицированной сборки под все конечные устройства б) унифицированное(одинаковое) поведение всей этой системы на разных девайсах.
Вот и имеем то, что имеем. Это не плохо, и не хорошо — это просто так есть. Согласно моим личным предпочтениям, я бы предпочел собрать аналогичную схему на том же микротике за примерно такие же деньги. В конкретно вашей же ситуации — выбор за вами, и собиралось оно, видимо, несколько раньше текущего времени, а тогда и имкротики были другие, и стоить могли дороже.
Но ведь от клиента не требовалась магия по поддержке чего-то нового, достаточно было не включать сжатие.
Там «собака зарыта», видимо, таки в сборке. Т.е. deprecated-сжатие не собирали, а из списка поддерживаемых сервером опций не убрали. Вот и получилось:
Клиент: — Слушай, сервер, а ты поддерживаешь comp-lzo?
Сервер (на голубом глазу, сверяясь со списком, подсунутым при сборке): — Да.
Клиент: — #sl0sdfl(*jsei
Сервер:… Нихрена не понял, что ты сказал, но, на всякий случай «сам урод».
Я почему возмутился — автор статьи нам рассказывает что OpenVPN сам по себе дико смышленый и сам все согласовывает, а по факту оказалось что нет, сообразить отключить сжатие он не может.
Ну, он достаточно смышленный для того, чтобы сопоставить свой список с тем, что ему сервер прислал. Он вообще действительно достаточно смышленный. Просто сервер неправильный список прислал — и это вопрос к сборщику. Я на эти грабли сам наступал, когда один мой товарищ пытался как раз openVPN'ом подружить 2 D-Link'а соседних моделей (на буковку в конце различались) на «одной и той же версии OpenWRT» с «одним и тем же билдом OpenVPN». Я в предыдущем предложении специально кавычки так расставил, потому что дебаг выявил, что эти девайсы с идентичным конфигом отдавали разные списки поддерживаемых опций, и со сжатием так и не завелись.
Честно говоря весь параграф «Об игнорировании реальных проблем» больше похож на маркетинговый буллшит, какие-то абстрактные преимущества и недостатки без единого слова конкретики.
А вот с маркетинговой сутью всей этой бучи вокруг WG однозначно соглашусь. Собственно, сам продукт достаточно интересен, но а) ему еще расти и расти, б) его пиарят как замену всему, включая те вещи, заменой которым он не является, в) совершенно не известно, что с ним произойдет в процессе «натягивания совы на глобус», т.е. попытки подвести продукт под вещи, заявленные в пункте «б».
Просто природа самого проекта OpenWRT (и dd-wrt, до кучи) такова, что «немного через жопу» — это нормальное состояние. Задача «собрать некую штуку, которая будет работать на тысячах устройствах, которые не предназначены для запуска этой штуки в условиях отсутствия спецификаций на эти устройства»Ну это вообще природа у опенсорса такая: делается в качестве хобби, квалификация разная бывает, бесплатно спеки не всегда дают и тд.
Ну про тысячи это немного преувеличено.
При всем многообразии роутеров поддерживаемых платформ не так много и их толи десяток толи два десятка, а специфичные вещи для конкретных моделей пишутся в конфигах для них. Тут больше вопрос экономии места возникает, тк объемы флеша и оперативки у роутера ограничены.
При всем многообразии роутеров поддерживаемых платформ не так много и их толи десяток толи два десятка, а специфичные вещи для конкретных моделей пишутся в конфигах для них.
На выходе может получиться весьма и весьма разный результат. Лично наблюдал, как два роутера из одного модельного ряда на одной и той же версии прошивки OpenWRT не могли сконнектиться по OpenVPN. Так что там многое что роляет. Производители роутеров — боооольшие затейники, и своя специфика может вылезти на любом из роутеров из именно что тысяч…
Просто природа самого проекта OpenWRT (и dd-wrt, до кучи) такова, что «немного через жопу» — это нормальное состояние. Задача «собрать некую штуку, которая будет работать на тысячах устройствах, которые не предназначены для запуска этой штуки в условиях отсутствия спецификаций на эти устройства» — она сама по себе достаточно ресурсоемка, нетривиальна
какое это всё имеет отношение к поддержке openvpn?!? вообще аппаратно-зависимые вещи — только малая доля проекта openwrt
какое это всё имеет отношение к поддержке openvpn?!?
Ну, например, косяки сборки OpenVPN под OpenWRT иногда ошибочно относят к косякам самого OpenVPN, что мы и видели выше по истории этого треда… А так — да, никакого. Проблемы OpenVPN в контексте работы сервера из-под OpenWRT к OpenVPN отношения не имеют никакого, о чем я и говорю.
вообще аппаратно-зависимые вещи — только малая доля проекта openwrt
Тем не менее они вполне себе «аффектят» работу некоторых вещей, т.к. с одной стороны это только малая доля проекта, а с другой — самая сложная в тестировании. Одно дело для разработчика собрать проект и потестить на своей личной железяке или в виртуалке, убедиться, что все работает, а совершенно другое дело — прогнать все возможные конфигурации на тысячах доступных потребительских девайсов. Вот второй случай — нереализуем в принципе. Вот и имеем то, что имеем. С одной стороны есть относительно протестированная бОльшая часть проекта, и есть аппаратно-зависимые вещи, поверх которых это все работает, которые, откровенно говоря, вживую на всех доступных комбинациях никто не тестил, ибо нереализуемо и бессмысленно…
А в данном случае понизить версию было нельзя, тк старые (> 5 лет) репозитории OpenWRT были уже выпилены.
Безопасность — мой главный приоритет, и сейчас у меня нет оснований полагать, что IKE или TLS как-то скомпрометированы или поломаныПонимаете, некоторые предпочитают секс с девушкой, а не с IPSec.
Если кратко: нет, не быстрее.А я видел обратное. На обычном домашнем двухъядерном MIPS-роутере WG позволил выжать больше, чем юзерспейсный OpenVPN.
Хотя самый большой недостаток IPsec (с точки зрения простоты настроек) — это огород с PKI (если использовать сертификаты), в то время как shared secret ну совсем не вариант.
Автор пишет про ipsec. И да OVPN — тормоз, это очевидно.
На текущий момент это не серебряная пуля, которая решит все вопросы с этим сложно не согласится.
Но, например, у нас в конторе был OpenVPN и сейчас все дружно переезжаем на Wireguard, потому что проще и работает лучше. С OpenVPN достаточно много было мучений, потому что у одного работает, а у другого нет, а с WG всё взлетает и все довольны.
У WireGuard есть своя специфика, нужно немного руками поработать, чтобы всё заработало как надо, но по скорости он прям очень хорош.
Я думаю, что в ближайшее время люди начнут работать над недостатками и в итоге всё станет более удобным, а пока будем чуть-чуть писать скрипты, пилить велосипеды и радоваться тому, что имеем.
У меня самый весёлый use-case, который не описан в статье — это то, что можно пробросить туннель со смартфона до сервера )
Будет спрос. Будет развитие.
с клиентской версии 2.4
Это только относительно шифрования, все остальное давно работает. В статье как раз говорится, что у них разные подходы с точки зрения архитектуры, WG сделан чтобы быстро поднять туннель, остальные популярные решения рассчитаны на более серьезные задачи. Конечно, следим за WG и ждем, лично я хочу tcp протокол))
Зачем вы хотите именно TCP?
У WireGuard есть своя специфика, нужно немного руками поработать, чтобы всё заработало как надо, но по скорости он прям очень хорош.
Один из серьёзных недостатоков — невозможность выяснить, жив ли клиент, равно как и невозможность что-то сделать в момент когда он подцепился. Можно косвенно это выяснить по времени последнего пакета (при включенном keepalive), но это криво и ненадёжно.
Если же есть только один VPN сервер, всем клиентам можно дать статический IP, отслеживать и ограничивать их соединения не нужно — да, хороший и простой вариант, очень шустрый к тому же.
У меня всё конфигурирование и установка соединения обёрнуто в сервис, который периодически пингует сервер, поэтому я всегда могу понять когда клиент жив. Да, костыть, но что делать.
Собственно об этом и говорил, что пока есть недостатки, но я думаю, что их решат со временем.
ChaCha20 — это потоковый шифр, который легче внедрить в программное обеспечение. Он шифрует один бит за раз. Блочные протоколы, такие как AES, шифруют блок по 128 бит за раз.
Bullshit. ChaCha20 генерирует блоки размером 512 бит, которые затем xor-ятся с шифруемыми данными.
аппаратное ускорение творит чудеса
Для домашнего роутера OpenWRT WireGuard настраивается в разы проще, чем OpenVPN и уж тем более IPSec. А работает не хуже. Проверено.
Поэтому автор прав, WG для людей, а не для корпораций.
Почему-то всегда рассматривал WG как "домашний" VPN — секундная настройка и можно цепляться с телефона к домашней сети.
В моем случае WG вообще идёт как add-on к HomeAssistant — установка и настройка из web интерфейса HA.
Сравнив количество теледвижений для подъёма VPN сервера на домашнем mikrotik и на WS, сделал выбор в пользу последнего.
Расскажете подробнее о решении?
На Хабре есть статьи по нему.
До этого был OpenVPN и IPSec (остался и сейчас, но не использую). WireGuard нравится больше.
>Вообще, вы задумывались когда-нибудь об отказе от Cisco?
вообще улыбнул. Автор, ты действительно считаешь, что всё в мире работает на Cisco?
И все эти описанные проблемы с негибкостью и возможным апгрейдом решаются другим приложением, а wg делает то что и должен — устанавливает туннель.
Собственно говоря, сам работаю в такой компании, и wireguard один из самых удобных инструментов что мы предлагаем.
для меня абсолютный шоустопер - отсутствие возможности передачи информации о маршрутах на сторону клиента. т.е. по сути пока получается, что wg это аналог gif/gre тунелей, но с довеском в виде шифрования.
WireGuard создан в первую очередь для личного использования.
Простота и удобство? - есть
Быстрый? - нужно смотреть сколько вы можете выжать IN + OUT вместе на WireGuard и на OpenVPN. Последний тихо курит в сторонке.
Все остальное это бизнес решения, а не для личного использования. Так что плюсов больше у WireGuard for personal use.
Не знаю как профессионалы оценивают, а вот мне - не айтишнику - wg очень сильно помог. На фоне блокировок многих VPN сервисов wg стал спасением. Аж камень с души упал, когда заблокированные без моего мнения сайты, вновь стали доступны!
Единственное, что удивляло по первости, когда только wg и VPS изучал, так это почему скорость резко падала, с 60 до 3 МБ. Чего так?
Ещё один знакомый показал, что с wg можно напрямую в Tor и I2P. Вот это для меня было приятной неожиданностью. К слову может кто в лс подсказать как это можно сделать? Хочу на своём wg попробовать))
Почему не стоит пользоваться WireGuard