Pull to refresh

Comments 61

UFO just landed and posted this here
PPTP не обеспечивает должный уровень безопасности, не всегда проходит через firewall и, честно говоря, это, пожалуй, самый неудачный туннель, который можно использовать в реалиях сего дня. Зато поддерживается практически везде, да. Но если вам нужна поддержка как можно большего количества устройств, то стоит использовать IPsec без L2TP (лучше IKEv2, но можно и IKEv1). Про него скоро будет статья.
Про него скоро будет статья.
Спасибо. А то, увидев ник, сразу захотел напомнить про обещание насчёт IKEv2 в habrahabr.ru/post/243915/#comment_8161967

А то у меня уже выкипел мой «гуманитарный» мозг на стадии поднятия BIND и добавлении подсети (виртуальной) для StrongSwan VPN на Амазоне, «не выходит каменный цветок».
Да, я тоже очень хочу рецепт для ikev2. У меня так и не получилось сертификаты нужные самовыдать, а с обычным ssl-сертификатом мой win server 2k8r2 отказывается этот vpn хостить.
ИМХО не корректно сравнивать ipsec с pptp. Это протоколы разных уровней.
А зачем собственно использовать TCP? Это противоестественно для openvpn, и не рекомендуется. Да может в каких-то случаях это и нужно (если заблокирован UDP), но так нужно и написать: «как настраивать openvpn если приходится использовать TCP».
Эти изменения актуальны и для UDP. Возможно, я неоднозначно составил последнее предложение в конце технической информации, надо бы переписать. Это изменение повысило скорость с 30 до 80 МБит/с через UDP.
в таком случае просто не понятно почему это влияет на UDP, описан только TCP юзкейс.
Дополнил статью. Надеюсь, так станет чуточку понятнее.
А через прокси только TCP работать будет?
Это как? Через какой прокси?
По логике, если нет ограничений от OpenVPN, через сокс и UDP должен работать.
Через SOCKS5 в режиме UDP отлично работает OpenVPN :)
Мне tcp пришлось использовать из-за того, что в филиале стоит Mikrotik, который умеет только tcp openvpn.
Имеет ли смысл прописывать sndbuf 0 и rcvbuf 0 со стороны клиента при подключении через VPN-провайдер? Прописать эти настройки на стороне сервера возможности нет.
Вы никогда не добьётесь скорости канала по ВПН-соединению, т.к. есть такое понятие, как overhead, который складывается из заголовков, в которые инкапсулируются данные. А у ВПН их много, много больше, чем у обычного IP-трафика, т.к. если используется тунель, это как минимум пара IP-заголовков и пара транспортных. И чем меньше пакеты, тем больше доля оверхеда. Если пакеты совсем крошечные, скажем, меньше 100 байт, что характерно для VoIP, оверхеад может достигать 50%, т.е. на канале 100 мегабит 50 будет уходить на служебную информацию. Это первое. Второе. Установка значения MTU большим, чем минимальное на маршруте приведёт только фрагментации уже шифрованных пакетов, что в случае cisco, например, должно избегаться, т.к. это приводит к деградации производительности. В случае openVPN не уверен насчёт деградации, но никакого положительного эффекта от такой манипуляции не будет определённо.
Все, в целом, верно. OpenVPN по умолчанию настроен так, чтобы TCP-пакеты проходили через линк с MTU >= 1450 без фрагментации. Увеличение MTU туннеля до огромных значений уменьшает загрузку CPU, что часто помогает добиться больших скоростей в случае маломощных устройств, вроде домашних роутеров, либо же серверов на линках около гигабита.
А оверхед у OpenVPN может быть около 80 байт, т.е. около 80% для VoIP-трафика из вашего примера, но обычно он меньше.
По поводу фрагментации ещё одно интересное наблюдение. Если выставить MTU больше минимального на маршруте, то, как я писал выше, будет выполняться фрагментация пакетов после шифрования. При этом, все дополнительные заголовки ВПН, которые формируют значительную долю оверхеада, будут представлены только в первом фрагменте, все остальные фрагменты будут без доп. ВПН заголовков. Т.е. теоретически, больший MTU может позволить уменьшить оверхеад, но только для больших пакетов. Но за этим сразу же следует негативный эффект, по крайней мере в случае с ipsec — деградация производительности. Причина следующая — при фрагментации пакетов после шифрования, терминирующий канал роутер перед расшифровкой пакета должен сначала его собрать, т.е. сборка всех пакетов, фрагментированных таким образом, ложиться на плечи роутера. Если же пакеты будут фрагментироваться до шифрования, они могут быть расшифрованы без сборки на стороне роутера, сборкой в этом случае будет заниматься конечный узел.
Занятное наследство.
На багтрекере у них проголосовать за баг нельзя, как я понял? Патч есть, что им ещё нужно-то.
Голосовать нельзя. Они обсудили в IRC эти изменения, но как-то процесс заглох. Возможно, думают над решением.
А вот спасибо за ценную информацию, обязательно опробую, у меня как раз клиенты и сервер на разных ОС.
с сервером под Linux после изменений скорость внутри тоннеля выросла более чем в два раза. с сервером под FreeBSD улучшение всего 10-15%, что можно списать на статистическую погрешность. клиенты в обоих случаях Windows 7. за статью спасибо, пошёл было ставить в карму, а там уже.
Интересно, мы как-то соединяли два офиса через 100-мегабитный канал и OpenVPN. Криво, конечно, но тогда это был лучший вариант, GRE over IPSEC не было возможности настроить. Я тестировал тогда использование канала и пришел к выводу, что существенного снижения скорости по сравнению с «сырым» линком нет. Вроде было 70-80 мбит/с, разницу я списал на оверхед. А оказывается, вот оно как )
Если вы использовали UDP, и пинг между офисами был в пределах 20 мс, то это вполне возможно.
Вы правы, был именно UDP и пинг был в пределах 3-5 мс (внутригородская сеть провайдера).
Статья супер! Но в статье совершенно не упомянут совершенно необходимый момент — нагрузка на процессор от OpenVPN. Если при 100 мегабитах более-менее средний проц сможет отработать, то на гигабите и более — уже точно начнутся проблемы даже у серверных процессоров. Кроме того, не уверен, что OpenVPN хорошо распределит нагрузка по ядрам отработает при наличии большого числа ядер, а не просто съест одно ядро целиком и начнет дропать пакеты.

Вот этот момент был бы даже более интересен, чем домашнее использование.
OpenVPN однопоточный, и для того, чтобы нагрузка распределялась по ядрам, запускают несколько OpenVPN'ов и объединяют их через bonding или teaming.
Вообще, насколько странным бы это не казалось, тормозит больше всего не шифрование, а код изменения TCP MSS! Если отключить его параметром mssfix 0, то на моем стареньком компьютере скорость взлетает с 300 Мбит/с до ~750 Мбит/с при прямом гигабитном подключении.
Если нужна такая статья, могу написать.
Напишите, пожалуйста. Интересно.
Я тоже думаю, что очень нужна :) Что-то в стиле «гигабит по OpenVPN» — это будет ну очень круто.
Да, напишите пожалуйста. Интересуют все возможные советы по увелечению скорости, не в ущерб безопасности.

Спасибо за статью, скорость на tcp выросла минимум в три раза.
что то не помогло mssfix 0
не подскажите поподробнее??
ну в ветке речь про нагрузку на процессор.
Ну, я прогоняю гигабит с AES-128-CBC, SHA1, буфферами в 0 и mssfix 0 без проблем на одном процессоре с загрузкой не под 100. У вас какого порядка скорости-то?
Это нужно спрашивать у разработчиков, т.к. исходников этого продукта нет, и он использует OpenVPN 3.
Благодарю, ну по крайней мере в исходниках подобного кода не нашлось.
Можешь порекомендовать какую-то достойную открытую альтернативу OpenVPN Connect?
Если для Android, то OpenVPN for Android. У него открыты исходные коды и он основан на OpenVPN git-срезе, но подключается, как правило, дольше, чем OpenVPN Connect, и статистика у него не очень, зато настроек больше, и можно вручную все настроить, даже есть нет конфиг-файла, а только ключи.
Использую ssh как сокс5 прокси. Подтормаживает, если сразу открывать много вкладок в браузере. Можно ли как-то это все ускорить?
Спасибо за hpn-ssh — стало получше.
Можете попробовать sshuttle: Transparent proxy server that works as a poor man's VPN. Forwards over ssh. Doesn't require admin. Works with Linux and MacOS. Supports DNS tunneling.
Не подходит, у меня виндовс. Но я поставил на сервер hpn-ssh, как советовал ValdikSS — вроде стало лучше.
А какие недостатки у большого буфера? Т.е. почему 393216, а не, к примеру, 2097152?
В случае с UDP, я предполагаю, чуть увеличится задержка (latency), что негативно скажется, например, на VoIP. Т.е. ОС вместо того, чтобы отбрасывать пакеты, будет копить их в буфере. В случае с TCP, хм, вроде особых проблем нет.
Еще в текущей стабильной версии OpenVPN нельзя задать буфер больше 999999. Будет исправлено в 2.3.9.
Дейсвительно OpenVPN стал летать, спасибо!
А у меня не стал летать, как ни старался… На мегабитной линии smb разгоняется только до 120 килобит, остальной канал свободен. Пинг 150. Ничего не дают ни попытки увеличить буфера (в смысле, буферы) — от 0 до 500К, ни загадочный mssfix, ни тип порта c UDP на TCP и обратно… Кстати, на плохом канале tcp ощутимо помогает — потери падают почти до нуля. Правда, пинг вырастает до одной секунды (*нервный смех*)
Вы не путаете биты и байты?
Путаю иногда. 11 КБ — это биты, или байты? ))

Шучу. iperf показывает загрузку канала на 1/10… Так что всё правильно.
Привет, у меня на такой линии, тоже много траблов, даже без openvpn много проблем. Что удалось выяснить — windows, до 10, к такому каналу не приспособлен. Можно тюнить, но не сильно поможет. Почитайте, если интересно. Samba у меня даже на 50-70 мс уже тупит.
Имхо, основная проблема, в данном контексте(Samba), это то, что она для локальной сети разрабатывалась где пинги маленькие. Я столкнулся с этим не только на примере самбы. Вы можете попробовать без openvpn на длинной линии запустить самбу, даже интересно что будет. Опять же имхо, основная проблема алгоритм разгона TCP. Если сделать быстрый старт, вроде есть такие настройки, то начинаются много потерь, на коротких линиях, то есть, либо одно либо другое. Максимальная скорость у iperf на длинных линиях при "-l 1M"(маленькая L), максимально для TCP. В общем я бросил эти попытки с вердиктом, не судьба. Возможно надо тюнить самбу, а не openvpn. Если что-то получится напишите пару строк, можно в личку, буду при много благодарен.
Шестое чувство настаивает, что тюнить эту штуку обойдётся себе дороже. Оптимист внутри меня считает необходимым рассмотреть вариант бросить самбу вообще и перейти на WebDav. Он поддерживается в windows без дополнительного софта, и его можно смонтировать как сетевой диск. Единственное ограничение — 4 гигабайта на файл.
Only those users with full accounts are able to leave comments. Log in, please.

Articles