Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
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.
А через прокси только TCP работать будет?
Это как? Через какой прокси?
Через HTTPS или Socks4/5.
BigD, да.
BigD, да.
https
Через 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-трафика из вашего примера, но обычно он меньше.
А оверхед у OpenVPN может быть около 80 байт, т.е. около 80% для VoIP-трафика из вашего примера, но обычно он меньше.
По поводу фрагментации ещё одно интересное наблюдение. Если выставить MTU больше минимального на маршруте, то, как я писал выше, будет выполняться фрагментация пакетов после шифрования. При этом, все дополнительные заголовки ВПН, которые формируют значительную долю оверхеада, будут представлены только в первом фрагменте, все остальные фрагменты будут без доп. ВПН заголовков. Т.е. теоретически, больший MTU может позволить уменьшить оверхеад, но только для больших пакетов. Но за этим сразу же следует негативный эффект, по крайней мере в случае с ipsec — деградация производительности. Причина следующая — при фрагментации пакетов после шифрования, терминирующий канал роутер перед расшифровкой пакета должен сначала его собрать, т.е. сборка всех пакетов, фрагментированных таким образом, ложиться на плечи роутера. Если же пакеты будут фрагментироваться до шифрования, они могут быть расшифрованы без сборки на стороне роутера, сборкой в этом случае будет заниматься конечный узел.
Занятное наследство.
На багтрекере у них проголосовать за баг нельзя, как я понял? Патч есть, что им ещё нужно-то.
На багтрекере у них проголосовать за баг нельзя, как я понял? Патч есть, что им ещё нужно-то.
А вот спасибо за ценную информацию, обязательно опробую, у меня как раз клиенты и сервер на разных ОС.
с сервером под Linux после изменений скорость внутри тоннеля выросла более чем в два раза. с сервером под FreeBSD улучшение всего 10-15%, что можно списать на статистическую погрешность. клиенты в обоих случаях Windows 7. за статью спасибо, пошёл было ставить в карму, а там уже.
Интересно, мы как-то соединяли два офиса через 100-мегабитный канал и OpenVPN. Криво, конечно, но тогда это был лучший вариант, GRE over IPSEC не было возможности настроить. Я тестировал тогда использование канала и пришел к выводу, что существенного снижения скорости по сравнению с «сырым» линком нет. Вроде было 70-80 мбит/с, разницу я списал на оверхед. А оказывается, вот оно как )
Статья супер! Но в статье совершенно не упомянут совершенно необходимый момент — нагрузка на процессор от OpenVPN. Если при 100 мегабитах более-менее средний проц сможет отработать, то на гигабите и более — уже точно начнутся проблемы даже у серверных процессоров. Кроме того, не уверен, что OpenVPN хорошо распределит нагрузка по ядрам отработает при наличии большого числа ядер, а не просто съест одно ядро целиком и начнет дропать пакеты.
Вот этот момент был бы даже более интересен, чем домашнее использование.
Вот этот момент был бы даже более интересен, чем домашнее использование.
OpenVPN однопоточный, и для того, чтобы нагрузка распределялась по ядрам, запускают несколько OpenVPN'ов и объединяют их через bonding или teaming.
Вообще, насколько странным бы это не казалось, тормозит больше всего не шифрование, а код изменения TCP MSS! Если отключить его параметром mssfix 0, то на моем стареньком компьютере скорость взлетает с 300 Мбит/с до ~750 Мбит/с при прямом гигабитном подключении.
Если нужна такая статья, могу написать.
Вообще, насколько странным бы это не казалось, тормозит больше всего не шифрование, а код изменения TCP MSS! Если отключить его параметром mssfix 0, то на моем стареньком компьютере скорость взлетает с 300 Мбит/с до ~750 Мбит/с при прямом гигабитном подключении.
Если нужна такая статья, могу написать.
А с Android, в случае приложения OpenVPN Connecот команды OpenVPN что либо надо делать и можно ли вообще?
Это нужно спрашивать у разработчиков, т.к. исходников этого продукта нет, и он использует OpenVPN 3.
Благодарю, ну по крайней мере в исходниках подобного кода не нашлось.
Можешь порекомендовать какую-то достойную открытую альтернативу OpenVPN Connect?
Использую ssh как сокс5 прокси. Подтормаживает, если сразу открывать много вкладок в браузере. Можно ли как-то это все ускорить?
А какие недостатки у большого буфера? Т.е. почему 393216, а не, к примеру, 2097152?
В случае с UDP, я предполагаю, чуть увеличится задержка (latency), что негативно скажется, например, на VoIP. Т.е. ОС вместо того, чтобы отбрасывать пакеты, будет копить их в буфере. В случае с TCP, хм, вроде особых проблем нет.
Еще в текущей стабильной версии OpenVPN нельзя задать буфер больше 999999. Будет исправлено в 2.3.9.
Дейсвительно OpenVPN стал летать, спасибо!
А у меня не стал летать, как ни старался… На мегабитной линии smb разгоняется только до 120 килобит, остальной канал свободен. Пинг 150. Ничего не дают ни попытки увеличить буфера (в смысле, буферы) — от 0 до 500К, ни загадочный mssfix, ни тип порта c UDP на TCP и обратно… Кстати, на плохом канале tcp ощутимо помогает — потери падают почти до нуля. Правда, пинг вырастает до одной секунды (*нервный смех*)
Вы не путаете биты и байты?
Привет, у меня на такой линии, тоже много траблов, даже без openvpn много проблем. Что удалось выяснить — windows, до 10, к такому каналу не приспособлен. Можно тюнить, но не сильно поможет. Почитайте, если интересно. Samba у меня даже на 50-70 мс уже тупит.
Имхо, основная проблема, в данном контексте(Samba), это то, что она для локальной сети разрабатывалась где пинги маленькие. Я столкнулся с этим не только на примере самбы. Вы можете попробовать без openvpn на длинной линии запустить самбу, даже интересно что будет. Опять же имхо, основная проблема алгоритм разгона TCP. Если сделать быстрый старт, вроде есть такие настройки, то начинаются много потерь, на коротких линиях, то есть, либо одно либо другое. Максимальная скорость у iperf на длинных линиях при "-l 1M"(маленькая L), максимально для TCP. В общем я бросил эти попытки с вердиктом, не судьба. Возможно надо тюнить самбу, а не openvpn. Если что-то получится напишите пару строк, можно в личку, буду при много благодарен.
Имхо, основная проблема, в данном контексте(Samba), это то, что она для локальной сети разрабатывалась где пинги маленькие. Я столкнулся с этим не только на примере самбы. Вы можете попробовать без openvpn на длинной линии запустить самбу, даже интересно что будет. Опять же имхо, основная проблема алгоритм разгона TCP. Если сделать быстрый старт, вроде есть такие настройки, то начинаются много потерь, на коротких линиях, то есть, либо одно либо другое. Максимальная скорость у iperf на длинных линиях при "-l 1M"(маленькая L), максимально для TCP. В общем я бросил эти попытки с вердиктом, не судьба. Возможно надо тюнить самбу, а не openvpn. Если что-то получится напишите пару строк, можно в личку, буду при много благодарен.
Шестое чувство настаивает, что тюнить эту штуку обойдётся себе дороже. Оптимист внутри меня считает необходимым рассмотреть вариант бросить самбу вообще и перейти на WebDav. Он поддерживается в windows без дополнительного софта, и его можно смонтировать как сетевой диск. Единственное ограничение — 4 гигабайта на файл.
побуду чуть-чуть некрофилом))) Данная проблема исправлена в 2.3.9 этим коммитом — community.openvpn.net/openvpn/changeset/c72dbb8b470ab7b25fc74e41aed4212db48a9d2f
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему OpenVPN тормозит?