Openvpn маленькая скорость. Почему OpenVPN тормозит

15.05.2019

Флешка

Описанная проблема присуща только ветке OpenVPN 2.3, в 2.4 размеры буферов не меняются без требования пользователя.

Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием OpenVPN и получают низкую скорость, сильно ниже скорости канала. У кого-то это может быть 20 Мбит/с при канале в 100 Мбит/с с обеих сторон, а кто-то еле получает и 400 Кбит/с на 2 Мбит/с ADSL/3G и высоким пингом. Зачастую, таким людям советуют увеличить MTU на VPN-интерфейсе до чрезвычайно больших значений, вроде 48000, или же поиграться с параметром mssfix. Частично это помогает, но скорость внутри VPN все еще очень далека от канальной. Иногда все сваливают на то, что OpenVPN - userspace-решение, и это его нормальная скорость, учитывая всякие шифрования и HMAC"и. Абсурд!

Немного истории

На дворе июль 2004 года. Типичная скорость домашнего интернета в развитых странах составляет 256 Кбит/с-1 Мбит/с, в менее развитых - 56 Кбит/с. Ядро Linux 2.6.7 вышло не так давно, а 2.6.8, в котором TCP Window Scale включен по умолчанию, выйдет только через месяц. Проект OpenVPN развивается уже 3 года как, к релизу готовится версия 2.0.
Один из разработчиков добавляет код, который устанавливает буфер приема и отправки сокета по умолчанию в 64 КБ, вероятно, чтобы хоть как-то унифицировать размер буфера между платформами и не зависеть от системных настроек. Однако в Windows что-то поломали, и указание размера буферов у сокета приводит к странным проблемам с MTU на всех адаптерах в системе. В конечном итоге, в релиз OpenVPN 2.0-beta8 попадает следующий код:
#ifndef WIN32 o->rcvbuf = 65536; o->sndbuf = 65536; #endif

Немного технической информации

Если вы пользовались OpenVPN, вы знаете, что он может работать как через UDP, так и через TCP. Если на TCP-сокете установить какое-то маленькое значение буфера, в нашем случае 64 КБ, то алгоритм подстройки TCP-окна просто не сможет выйти за это значение.
Что же это значит? Предположим, вы подключаетесь к серверу в США из России через OpenVPN со стандартными значениями буферов сокета. У вас широкий канал, скажем, 50 МБит/с, но в силу расстояния, пинг составляет 100 мс. Как вы думаете, какой максимальной скорости вы сможете добиться? 5.12 Мбит/с. Вам необходим буфер размером как минимум 640 КБ, чтобы загрузить ваш 50 Мбитный канал.
OpenVPN через UDP будет работать несколько быстрее из-за собственной реализации пересылки пакетов, но тоже далеко не идеально.

Что делать?

Как вы могли уже догадаться, данный размер буфера все еще применяется в самом последнем релизе OpenVPN. Как же нам исправить ситуацию? Самый корректный вариант - запретить OpenVPN менять размер буферов у сокета.
Нужно добавить следующие строки как в серверный, так и в клиентский конфигурационные файлы:
sndbuf 0 rcvbuf 0
В этом случае, размер буфера будет задаваться настройками ОС. Для Linux и TCP это значение будет меняться согласно значениям из net.ipv4.tcp_rmem и net.ipv4.tcp_wmem, а для UDP - фиксированное значение net.core.rmem_default и net.core.wmem_default, деленное на два.

Если же по какой-то причине нет возможности поменять конфигурационные файлы клиента, следует отдавать достаточно большие размеры буферов с сервера:
sndbuf 0 rcvbuf 0 push "sndbuf 393216" push "rcvbuf 393216"
UDP несколько отличается от TCP. У него нет аналога Window Scale, ему не требуются подтверждения о доставке пакета на транспортном уровне, но низкий размер буфера приема может замедлить и его, если буфер забивается раньше, чем OpenVPN успевает его считывать. Если скорость внутри туннеля кажется вам низкой даже с изменениями, описанными выше, то, возможно, имеет смысл либо увеличить размер буфера для всей системы целиком, увеличив net.core.rmem_default и net.core.wmem_default, либо всегда указывать определенный размер буфера в конфигурационном файле:
sndbuf 393216 rcvbuf 393216 push "sndbuf 393216" push "rcvbuf 393216"

Но у меня Windows!

Если у вас и OpenVPN-сервер работает на Windows-машине, и все клиенты подключаются только из-под Windows, то поздравляю - вам ничего менять не нужно, у вас и так все должно работать быстро.

Описанная проблема присуща только ветке OpenVPN 2.3, в 2.4 размеры буферов не меняются без требования пользователя.

Немного истории

Немного технической информации

Что делать?

Но у меня Windows!

Производительность OpenVPN является для многих администраторов больной темой. Очень часто скорость внутри туннеля в разы отличается от скорости канала в меньшую сторону. К сожалению многие сетевые ресурсы дают по этому поводу неверные или вообще вредные советы, либо заявляют, что это "нормально", мол шифрование, работа в userspace, накладные расходы и т.д., и т.п. Мало кто пытается разобраться в реальных механизмах, влияющих на производительность OpenVPN, другая же часть просто дает готовые рекомендации, не поясняя откуда они получены и почему надо делать именно так.

Для примера возьмем один реальный случай. К нам обратился один знакомый системный администратор и пожаловался на низкую скорость через OpenVPN в двух новых торговых точках организации, в то время как в остальных местах проблем с производительностью канала не было.

Стали разбираться вместе и обнаружили, что при реальной скорости канала около 15 Мбит/с OpenVPN не разгоняется свыше 3-4 Мбит/с, да и это, по словам нашего коллеги, еще "хорошая" скорость.

Перед тем, как обратиться за помощью наш знакомый перепробовал массу рекомендаций из сети, но ни одна из них не принесла успеха. При этом выяснилось, что доступ к двум новым точкам осуществляется по радиоканалу и пинг, в зависимости от погодных условий, находится в пределах 100-200 мс, в то время как к остальным филиалам он гораздо ниже, около 50 мс.

А теперь самое время вспомнить о таком параметре, как размер буферов приема и отправки. Если не вдаваться в подробности работы сетевых протоколов, то размер буфера определяет максимальный объем данных, которые могут быть переданы за единицу времени. Наиболее чувствительный к размеру буфера протокол TCP, так как размер окна TCP, т.е. количества одновременно отправляемых пакетов не может превышать размер буфера. Протокол UDP работает иначе, но и его производительность также ограничена размерами буферов.

Проведем простую аналогию. Нам нужно перевезти некий груз из пункта A в пункты Б и В, в пункт Б ведет хорошая автомагистраль со средней скоростью 90 км/ч, а в пункт B грунтовка, разогнаться на которой можно до 45 км/ч. Понятно, что, используя один и тот-же транспорт за одно и тоже время в пункт Б удастся доставить в два раза больше груза, чем в пункт В.

В сетях все происходит аналогично. Исторически сложилось так, что размер буфера OpenVPN составляет 64 КБ, в Linux системах это значение устанавливается принудительно, в Windows вроде бы как отдается на откуп ОС, но по факту чаще всего мы имеем все те же 64 КБ. В этом несложно убедиться заглянув в лог:

Socket Buffers: R= S=

Теперь вооружимся калькулятором и посчитаем. Объем данных отправляемых или принимаемых за одну передачу не может превышать объем буфера, а количество отправок в единицу времени ограничено скоростью прохождения пакетов (пингом). Таким образом при пинге в 50 мс мы можем осуществить 20 передач в секунду, а при 200 мс только пять. Отправить за один раз мы можем 64 КБ, считаем, при 50 мс это будет 1280 КБ/сек (1,25 МБ/с) или 10 Мбит/с. Результат довольно неплохой и при общей скорости канала филиалов в 15-20 Мбит/с данное ограничение легко списать на служебный трафик, шифрование и т.п.

При пинге в 200 мс все гораздо более печально, мы упремся в потолок 320 КБ/с или 2,5 Мбит/с. Таким образом, путем несложных математических вычислений мы ответили на главный вопрос: "Почему тормозит OpenVPN". Как видим, ни шифрование, ни "накладные расходы" тут не причем, проблема в физических ограничениях канала.

Что же делать? Ответ прост - увеличивать размер буферов. Сделать это просто, откройте конфигурационный файл сервера и добавьте туда строки:

Sndbuf 524288
rcvbuf 524288

Это установит объем буферов в размере 512 КБ и позволит достичь скоростей при 50 мс - 80 Мбит/с, а при 200 мс - 20 Мбит/с.

В большинстве руководств советуют добавить такие же строки и в конфигурационный файл клиента, но как выяснилось на практике, со стороны клиента данные опции не работают, поэтому следует передать размеры буферов со стороны сервера, поэтому в конфигурацию сервера добавим еще две строки:

Push "sndbuf 524288"
push "rcvbuf 524288"

Чтобы убедиться, что настройки работают заглянем в лог на клиенте, там мы должны обнаружить примерно следующее:

Socket Buffers: R= S=

Также в ряде источников выражается мнение, что данная проблема (размеров буфера) актуальна только для Linux систем, а в Windows все должно работать быстро, однако уже у другого клиента мы обнаружили что в одном из филиалов, при проводном подключении, Windows Server 2008 R2 устанавливал размеры буферов в 8 КБ:

Socket Buffers: R= S=

А это даже при хорошем пинге в 50 мс не более 1,25 МБит/с, при скорости канала в десятки раз превышающем это значение.

В нашем же случае увеличение буфера до 512 КБ позволило достичь скоростей 11-12 Мбит/с, что вполне соответствует реальной скорости канала.

Поэтому мы советуем не полагаться на значения по умолчанию, а взять управление в свои руки, и реально оценив условия доступа рассчитать и установить необходимые значения буферов приема и отправки, что позволит полностью утилизировать канал и более не задаваться вопросом: "Почему OpenVPN тормозит?".

Сетевое оборудование ,

DIY или Сделай сам

Некоторые из нас не пользуются интернетом без VPN по тем или иным причинам: кому-то нужен выделенный IP, и проще и дешевле купить VPS с двумя IP, чем покупать адрес у провайдера, кто-то хочет получать доступ ко всем веб-сайтам, а не только разрешенным на территории РФ, третьим нужен IPv6, а провайдер его не предоставляет…
Чаще всего VPN-соединение устанавливают на самом устройстве, которое используется в определенный момент, что вполне оправданно, если у вас только один компьютер и один телефон, и вы их редко используете одновременно. Если же в вашей домашней сети множество устройств, или, например, есть такие, на которых VPN настроить нельзя, было бы удобнее поднимать туннель прямо на домашнем роутере, чтобы не задумываться о настройке каждого устройства по отдельности.

Если вы хоть раз устанавливали OpenVPN на свой маршрутизатор, вы, вероятно, были неприятно удивлены скоростью его работы. SoC "и даже дешевых роутеров без особых проблем пропускают через себя окологигабитный трафик, за счет выноса функций маршрутизации и NAT на отдельный чип, предназначенный исключительно для выполнения этой задачи, а основные процессоры таких роутеров довольно слабы, т.к. нагрузки на них практически никакой нет. Такой компромисс позволяет достигнуть высокой скорости работы роутера и заметно снизить цену готового устройства - маршрутизаторы с мощными процессорами стоят в несколько раз дороже, и позиционируются уже не только как коробка для раздачи интернета, но и в качестве NAS, торрентокачалки и домашней мультимедиа-системы.

Мой роутер, TP-Link TL-WDR4300, нельзя назвать новым - модель появилась в середине 2012 года, и обладает 560 МГц-процессором архитектуры MIPS32 74Kc, мощности которого хватает лишь на 20-23 Мб/с шифрованного трафика через OpenVPN, что по меркам скорости современного домашнего интернета совсем немного.
Как бы нам повысить скорость шифрованного туннеля? Мой роутер довольно функциональный, поддерживает 3x3 MIMO, да и вообще, хорошо работает, не хотелось бы его менять.
Так как сейчас принято делать 10-мегабайтные интернет-страницы, писать десктопные приложения на node.js и паковать их в 100-мегабайтный файл, наращивать вычислительные мощности вместо оптимизации, мы совершим нечто ужасное - переложим VPN-подключение на производительный одноплатный «компьютер» Orange Pi One, который установим в корпус роутера, не занимая существующие сетевые и USB-порты, всего за $9.99*!
* + доставка, + налоги, + на пиво, + MicroSD.

OpenVPN

Нельзя назвать процессор роутера совсем уж слабым - он способен шифровать и хешировать данные алгоритмом AES-128-CBC-SHA1 со скоростью 50 Мб/с, что заметно быстрее того, как работает OpenVPN, а современный поточный шифр CHACHA20 с хешем POLY1305 и вовсе развивает 130 мегабит в секунду! Почему же скорость VPN-туннеля такая невысокая? Все дело в переключении контекста между пространством пользователя и пространством ядра: OpenVPN шифрует трафик и общается с внешним миром в контексте пользователя, а в контексте ядра происходит сама маршрутизация. Операционной системе приходится постоянно переключаться то туда, то сюда, на каждый принятый или переданный пакет, а эта операция небыстрая. Данная проблема присуща всем VPN-приложениям, работающим через TUN/TAP-драйвер, и нельзя сказать, что проблема низкой скорости вызвана плохой оптимизацией OpenVPN (хотя, конечно, там есть места, которые нужно бы переделать). Ни один userspace VPN-клиент не выдает даже гигабита с отключенным шифрованием на моем ноутбуке, что уж говорить про системы со слабым процессором.

Orange Pi One

Одноплатник Orange Pi One от компании Xunlong - самое выгодное предложение по соотношению производительность/цена на данный момент. За $9.99* вы получаете добротный четырехядерный процессор ARM Cortex-A7, (стабильно) работающий на частоте 1008 МГц, и явно производительней соседей Raspberry Pi Zero и Next Thing C.H.I.P. по ценовой категории. На этом плюсы заканчиваются. Компания Xunlong уделяет софту своих плат ровно ноль внимания, и на момент запуска One в продажу не предоставляла даже файл конфигурации платы, не говоря уже о готовых образах. Allwinner - производитель SoC - тоже не особо трепетно относится к поддержке своего продукта. Их интересует только минимальная работоспособность в ОС Android 4.4.4, а значит, мы вынуждены использовать ядро версии 3.4 с Android-патчами. К счастью, есть энтузиасты, которые собирают дистрибутивы, правят ядро, пишут код для поддержки плат в mainline-ядре, т.е. фактически делают работу за производителя, заставляя это говно приемлемо работать. Для своих целей я выбрал дистрибутив Armbian, он часто и удобно обновляется (новые ядра устанавливаются прямо через пакетный менеджер, а не копированием файлов на специальный раздел, как это обычно бывает у Allwinner), да и поддерживает большинство периферии, в отличие от остальных.

Роутер

Для того, чтобы не загружать слабый процессор роутера шифрованием и ускорить наше VPN-соединение, мы можем переложить эту задачу на плечи более производительного процессора Orange Pi, подключив его к роутеру каким-либо образом. На ум приходит подключение либо по Ethernet, либо по USB - оба этих стандарта поддерживаются обоими устройствами, но не хотелось занимать уже существующие порты. К счастью, выход есть.

Микросхема USB-хаба GL850G, которая используется в роутере, поддерживает работу 4 USB-портов, два из которых не распаяны. Неясно, почему производитель не стал их распаивать, предполагаю, чтобы не дать возможность пользователям подключить сразу 4 устройства с высоким потреблением тока (например, жестких дисков), т.к. штатный блок питания роутера не рассчитан на такую нагрузку. В любом случае, это нам на руку.

Для того, чтобы получить еще один USB-порт, достаточно допаять два провода к 8(D-) и 9(D+) или 11(D-) и 12(D+) пинам.

Однако недостаточно просто так подключить два USB-устройства и надеяться, что все заработает само собой, как это бы произошло с Ethernet. Во-первых, нам нужно заставить одного из них работать в режиме USB Client, а не USB Host, во-вторых, нам нужно определиться с тем, как устройства будут определять друг друга. Существует множество драйверов так называемых USB Gadgets (по названию подсистемы Linux-ядра), которые позволяют эмулировать различные типы USB-устройств: сетевой адаптер, аудиокарту, клавиатуру и мышь, флешку, фотоаппарат, консоль через последовательный порт. Так как наше устройство будет работать с сетью, нам лучше всего подойдет эмуляция Ethernet-адаптера.

Существует три стандарта Ethernet-over-USB:

Remote NDIS (RNDIS) . Устаревший стандарт от Microsoft, использовался преимущественно во времена Windows XP.
Ethernet Control Model (ECM) . Простой стандарт, который инкапсулирует Ethernet-фреймы в USB-пакеты. Отлично подходит для проводных модемов с USB-подключением, где удобно передавать кадры без обработки, но из-за своей простоты и ограничений USB-шины работает не слишком быстро.
Ethernet Emulation Model (EEM) . Более умный протокол, который учитывает ограничения USB и оптимально агрегирует несколько фреймов в один, повышая таким образом пропускную способность.
Network Control Model (NCM) . Самый новый протокол. Обладает преимуществами EEM и еще больше оптимизирует работу с шиной.

Чтобы заставить работать любой из этих протоколов на нашей плате, как всегда, придется встретиться с некоторыми трудностями. Из-за того, что Allwinner интересуют только Android-части ядра, нормально работает только Android Gadget - тот код, который реализует связь с adb, экспорт устройства по протоколу MTP и эмуляцию флешки на Android-устройствах. Сам Android Gadget поддерживает и протокол RNDIS, но в ядре Allwinner он сломан. Если вы попробуете скомпилировать ядро с любым другим USB Gadget, устройство просто не появится в системе, что бы вы ни делали.
Для решения проблемы, по-хорошему, необходимо найти место инициализации USB-контроллера в модифицированном разработчиками коде Android-гаджета android.c, но существует и обходной маневр, чтобы заставить работать, как минимум, эмуляцию Ethernet через USB:
--- sun8i/drivers/usb/sunxi_usb/udc/sunxi_udc.c 2016-04-16 15:01:40.427088792 +0300 +++ sun8i/drivers/usb/sunxi_usb/udc/sunxi_udc.c 2016-04-16 15:01:45.339088792 +0300 @@ -57,7 +57,7 @@ static sunxi_udc_io_t g_sunxi_udc_io; static u32 usb_connect = 0; static u32 is_controller_alive = 0; -static u8 is_udc_enable = 0; /* is udc enable by gadget? */ +static u8 is_udc_enable = 1; /* is udc enable by gadget? */ #ifdef CONFIG_USB_SUNXI_USB0_OTG static struct platform_device *g_udc_pdev = NULL; Этот патч насильно включает режим USB-клиента, что позволяет использовать обычные USB Gadgets из Linux.
Теперь следует пересобрать ядро с этим патчем и необходимым гаджетом. Я выбрал EEM, т.к. по результатам тестов он оказался производительней NCM.
Команда Armbian предоставляет очень простую и удобную сборочную систему для всех поддерживаемых плат в дистрибутиве. Достаточно скачать ее, положить наш патч в userpatches/kernel/sun8i-default/otg.patch , немного отредактировать compile.sh и выбрать необходимый gadget:

Ядро соберется в deb-пакет, который не составит труда установить на плату через dpkg .
Остается только подключить плату по USB и настроить наш новый сетевой адаптер на получение адреса через DHCP. Для этого необходимо добавить примерно следующее в /etc/network/interfaces:
auto usb0 iface usb0 inet dhcp hwaddress ether c2:46:98:49:3e:9d pre-up /bin/sh -c "echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role" MAC-адрес лучше задать вручную, т.к. он будет случайным при каждой перезагрузке устройства, что неудобно и хлопотно.
Подключаем MicroUSB-кабель к OTG-разъему, подключаем питание с роутера (его можно подавать на 2 и 3 пины гребенки, а не только на разъем питания).

Осталось настроить роутер. Достаточно установить пакет с EEM-драйвером и добавить наше новое сетевое USB-устройство в бридж локальной firewall-зоны:
opkg install kmod-usb-net-cdc-eem

Чтобы маршрутизировать весь трафик в VPN-туннель, нужно либо добавить SNAT-правило на IP-адрес платы на стороне роутера, либо раздавать в качестве адреса шлюза адрес платы через dnsmasq. Последнее делается добавлением следующей строки в /etc/dnsmasq.conf:
dhcp-option = tag:lan, option:router, 192.168.1.100 где 192.168.1.100 - IP-адрес вашей платы. Не забудьте прописать адрес машрутизатора в настройках сети на самой плате!

Для изоляции контактов платы от контактов роутера использовалась меламиновая губка. Получилось как-то так:

Заключение

Работает сеть через USB на удивление быстро: 100-120 Мб/с, я ожидал меньшего. OpenVPN пропускает через себя около 70 Мб/с шифрованного трафика, что тоже не сильно много, но для моих нужд хватает. Крышка маршрутизатора закрывается неплотно, оставляя небольшой зазор. Эстеты могут выпаять Ethernet и USB Host-разъемы у платы, что позволит крышке закрыться полностью, и еще место останется.
А лучше не заниматься такой порнографией и купить