Openvpn низкая скорость копирования файлов

Обновлено: 25.01.2025

Производительность 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=

При пинге в 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 тормозит?".

Некоторые из нас не пользуются интернетом без 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

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-устройства и надеяться, что все заработает само собой, как это бы произошло с 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 и еще больше оптимизирует работу с шиной.

Ядро соберется в 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-разъемы у платы, что позволит крышке закрыться полностью, и еще место останется.
А лучше не заниматься такой порнографией и купить

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

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

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

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

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

Что делать?

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

Время от времени, мне встречаются темы на форумах, в которых люди соединяют несколько офисов с использованием 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 попадает следующий код:

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

Что делать?

В этом случае, размер буфера будет задаваться настройками ОС. Для Linux и TCP это значение будет меняться согласно значениям из net.ipv4.tcp_rmem и net.ipv4.tcp_wmem, а для UDP — фиксированное значение net.core.rmem_default и net.core.wmem_default, деленное на два.

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

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

Но у меня Windows!

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

Почему тормозит OpenVPN? Размер буферов приема и отправки

Я испытываю чрезвычайно медленную скорость передачи OpenVPN между двумя серверами. На этот вопрос я позвоню на серверы Сервер А и Сервер Б.

Сервер A и сервер B работают под управлением CentOS 6.6. Оба расположены в центрах обработки данных с линией 100 Мбит, и передача данных между двумя серверами за пределами OpenVPN выполняется на скорости около 88 Мбит / с.

Однако, когда я пытаюсь передать любые файлы через соединение OpenVPN, которое я установил между Сервером A и Сервером B, я получаю пропускную способность около 6,5 Мбит / с.

Результаты теста от iperf:

Помимо этих тестов OpenVPN iperf, оба сервера практически полностью простаивают с нулевой нагрузкой.

Серверу А присвоен IP 10.0.0.1, и он является сервером OpenVPN. Серверу B присвоен IP 10.0.0.2, и он является клиентом OpenVPN.

Конфигурация OpenVPN для Сервера A выглядит следующим образом:

Конфигурация OpenVPN для Сервера B выглядит следующим образом:

Что я заметил:

1. Моей первой мыслью было узкое место на процессоре сервера. OpenVPN является однопоточным, и оба этих сервера работают на процессорах Intel Xeon L5520, которые не являются самыми быстрыми. Тем не менее, я top выполнил команду во время одного из тестов iperf и нажал, 1 чтобы посмотреть загрузку ЦП ядром, и обнаружил, что загрузка ЦП была очень низкой для каждого ядра:

2. Время пинга значительно увеличивается по туннелю OpenVPN во время работы iperf. Когда iperf не работает, время пинга по туннелю постоянно составляет 60 мс (нормально). Но когда iperf работает и интенсивно загружается, время пинга становится нестабильным. Ниже вы можете увидеть, насколько стабильно время пинга до 4-го пинга, когда я начал тестирование iperf:

3. Как упоминалось выше, я запускал iperf за пределами туннеля OpenVPN, и пропускная способность была нормальной -

Что я пробовал:

1. Я подумал, что сжатие может привести к загрязнению, поэтому я отключил сжатие, удалив comp-lzo оба конфига и перезапустив OpenVPN. Без улучшения.

2. Несмотря на то, что ранее я обнаружил, что загрузка ЦП была низкой, я думал, что шифр по умолчанию может быть слишком интенсивным, чтобы система не отставала от него. Поэтому я добавил cipher RC2-40-CBC оба конфига (очень легкий шифр) и перезапустил OpenVPN. Без улучшения.

3. Я читал на различных форумах о том, как настройка фрагмента, mssfix и mtu-tun может помочь с производительностью. Я играл с несколькими вариантами, как описано в этой статье , но, опять же, без улучшений.

Любые идеи о том, что может быть причиной такой низкой производительности OpenVPN?

Большинство предложений здесь есть вещи, которые я уже попробовал: 1. проверить узкое место ЦП, 2. проверить скорость передачи без VPN, 3. переключить сжатие, 4. выбрать более быстрый шифр и т. Д. Не повезло ни с одним из них пока: - / Это странно. Помимо медленной скорости и высокого / нестабильного времени пинга, я не вижу других указаний на то, где может быть узкое место. Обе машины находятся в одном центре обработки данных? 60 мс в одном и том же дата-центре довольно высоки. Я мог бы попробовать, cipher none хотя я сомневаюсь, что это поможет. @Zoredache Извините - я не знал, где расположены серверы - сервер A находится в Далласе, а сервер B - в Сиэтле. Вы проверили MTU? Esp: параметры tun-mtu, фрагмента и mssfix? Документация

После большого количества настроек Google и настроек я нашел решение. Сейчас у меня стабильная скорость 60 Мбит / с и скорость до 80 Мбит / с. Это немного медленнее, чем скорость передачи, которую я получаю за пределами VPN, но я думаю, что это так же хорошо, как и получится.

Первым шагом была настройка sndbuf 0 и rcvbuf 0 в конфигурации OpenVPN как для сервера, так и для клиента.

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

Это июль 2004 года. Обычная скорость домашнего интернета в развитых странах составляет 256-1024 Кбит / с, в менее развитых странах - 56 Кбит / с. Linux 2.6.7 был выпущен не так давно, а 2.6.8, где TCP Windows Size Scaling будет включен по умолчанию, выпущен только через месяц. OpenVPN находится в активной разработке уже 3 года, версия 2.0 практически выпущена. Один из разработчиков решает добавить код для буфера сокетов, я думаю, чтобы унифицировать размеры буферов между операционными системами. В Windows что-то не так с MTU адаптеров, если установлены нестандартные размеры буферов, поэтому, в конце концов, он преобразуется в следующий код:

Далее автор описывает, как передать клиенту настройки размера буфера, если вы сами не управляете конфигурацией клиента.

После того, как я внес эти изменения, моя пропускная способность возросла до 20 Мбит / с. Затем я увидел, что загрузка ЦП на одном ядре была немного высокой, поэтому я удалил comp-lzo (сжатие) из конфигурации как на клиенте, так и на сервере. Эврика! Скорость передачи данных выросла до 60 Мбит / с, а скорость 80 Мбит / с.

Я надеюсь, что это поможет кому-то решить свои проблемы с медлительностью OpenVPN!

Я пытаюсь улучшить свою производительность OpenVPN, и это моя текущая настройка:

Я внес некоторые изменения в MTU и MSSFIX из того, что я нашел в Интернете.

Есть ли какие-либо изменения ядра, которые я мог бы сделать? Это коробка CentOS 6.x. Я нашел кое-что для BSD, но ничего не работало в Linux.

Я знаю, что TCP медленнее, чем UDP, но мне нужно иметь возможность выглядеть как трафик SSL, чтобы получить через брандмауэр в сети.

PING другому клиенту в сети, в который я подключился RDP.

Есть ли способ повысить производительность или отбросить пинг?

EDIT: Помогло бы установить настройку фрагментации?

4 ответа

Короткий ответ: отключить comp-lzo .

Я понимаю, что это старый пост, но я также страдал от плохой работы OpenVPN. Я все пробовал, настраивал MTU, менял буферы snd и rcv, зажимал mss, вы называете это. Загрузка процессора была незначительной.

По прихоти я отключил сжатие (удалил comp-lzo от клиента и сервера), а производительность увеличилась на 2-4x.

Итак, с помощью comp-lzo моя максимальная производительность составляла около 25-30 Мбит /с, и без нее я достигал 120 Мбит /с (моя скорость подключения к Интернету).

Сервер Xeon E5-2650, клиент Core i5-3320M. Оба запускают OpenVPN 2.3.10, AES-256-CBC, SHA512. Мой Chromebook Chrome также превысил скорость моего интернет-трафика. Производительность удвоилась на моих Android-клиентах (14 Мбит /с -> 30 Мбит /с), что соответствует скорости туннеля IKEv2.

TCP будет /много /медленнее, чем UDP, вызванный TCP-over-TCP . В основном, TCP полагается на падение /перегрузку пакетов для определения параметров соединения, а ваши соединения TCP-over-OpenVPN не испытывают ни одного из них. Но вы сказали, что это не вариант.

Вы также можете попробовать параметр mtu-disc , чтобы автоматически находить оптимальные настройки MTU для вашего соединения. В разных местах есть небольшие несоответствия, такие как настройка MTU OpenVPN, включая размер заголовка Ethernet. [ 1 ]

Ваш параметр tun-mtu является массовым, так как пакет 65 КБ будет иметь много проблем с задержкой, проходящих через Интернет (IPv4 jumbo пакеты составляют около 9000 байт, и в основном работают в локальных сетях). Попробуйте что-то под 1460 вместо 1300, чтобы узнать, является ли MTU вашей проблемой.

Даже если это может быть немного поздно, вы можете попробовать, что я сделал:

удалить все параметры mss, mtu и т. д.

выполните сканирование портов в вашем учреждении и выберите порт UDP, как правило, должны быть открыты 53 порта GRE /123 NDP:

Добавьте эти строки в конфигурацию вашего сервера (ref здесь )

Я не полностью понимаю эти настройки, но они наверняка помогли, некоторые говорят, что это помогает, по моему опыту, это увеличило мою пропускную способность на +/- 30%

Запустите сервер на одном из этих портов, и вам должно быть хорошо: P

Надеюсь, это поможет!

sndbuf /rcvbuf, установленный в 0, просто будет использовать настройки ОС

push используется, чтобы убедиться, что клиент настроен правильно, но там вам нужно значение.

Читайте также: