Я испытываю чрезвычайно медленную скорость передачи OpenVPN между двумя серверами. На этот вопрос я позвоню на серверы Сервер А и Сервер Б.
Сервер A и сервер B работают под управлением CentOS 6.6. Оба расположены в центрах обработки данных с линией 100 Мбит, и передача данных между двумя серверами за пределами OpenVPN выполняется на скорости около 88 Мбит / с.
Однако, когда я пытаюсь передать любые файлы через соединение OpenVPN, которое я установил между Сервером A и Сервером B, я получаю пропускную способность около 6,5 Мбит / с.
Результаты теста от iperf:
[ 4] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49184
[ 4] 0.0-10.0 sec 7.38 MBytes 6.19 Mbits/sec
[ 4] 0.0-10.5 sec 7.75 MBytes 6.21 Mbits/sec
[ 5] local 10.0.0.1 port 5001 connected with 10.0.0.2 port 49185
[ 5] 0.0-10.0 sec 7.40 MBytes 6.21 Mbits/sec
[ 5] 0.0-10.4 sec 7.75 MBytes 6.26 Mbits/sec
Помимо этих тестов OpenVPN iperf, оба сервера практически полностью простаивают с нулевой нагрузкой.
Серверу А присвоен IP 10.0.0.1, и он является сервером OpenVPN. Серверу B присвоен IP 10.0.0.2, и он является клиентом OpenVPN.
Конфигурация OpenVPN для Сервера A выглядит следующим образом:
port 1194
proto tcp-server
dev tun0
ifconfig 10.0.0.1 10.0.0.2
secret static.key
comp-lzo
verb 3
Конфигурация OpenVPN для Сервера B выглядит следующим образом:
port 1194
proto tcp-client
dev tun0
remote 204.11.60.69
ifconfig 10.0.0.2 10.0.0.1
secret static.key
comp-lzo
verb 3
Что я заметил:
1. Моей первой мыслью было узкое место на процессоре сервера. OpenVPN является однопоточным, и оба этих сервера работают на процессорах Intel Xeon L5520, которые не являются самыми быстрыми. Тем не менее, я topвыполнил команду во время одного из тестов iperf и нажал, 1чтобы посмотреть загрузку ЦП ядром, и обнаружил, что загрузка ЦП была очень низкой для каждого ядра:
top - 14:32:51 up 13:56, 2 users, load average: 0.22, 0.08, 0.06
Tasks: 257 total, 1 running, 256 sleeping, 0 stopped, 0 zombie
Cpu0 : 2.4%us, 1.4%sy, 0.0%ni, 94.8%id, 0.3%wa, 0.0%hi, 1.0%si, 0.0%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu3 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu8 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu9 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu10 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu11 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu12 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu13 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu14 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu15 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 946768k total, 633640k used, 313128k free, 68168k buffers
Swap: 4192188k total, 0k used, 4192188k free, 361572k cached
2. Время пинга значительно увеличивается по туннелю OpenVPN во время работы iperf. Когда iperf не работает, время пинга по туннелю постоянно составляет 60 мс (нормально). Но когда iperf работает и интенсивно загружается, время пинга становится нестабильным. Ниже вы можете увидеть, насколько стабильно время пинга до 4-го пинга, когда я начал тестирование iperf:
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=60.1 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=60.2 ms
** iperf test begins **
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=146 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=114 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=85.6 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=176 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=204 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=231 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=197 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=233 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=152 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=216 ms
3. Как упоминалось выше, я запускал iperf за пределами туннеля OpenVPN, и пропускная способность была нормальной - ~ 88 Мбит / с.
Что я пробовал:
1. Я подумал, что сжатие может привести к загрязнению, поэтому я отключил сжатие, удалив comp-lzoоба конфига и перезапустив OpenVPN. Без улучшения.
2. Несмотря на то, что ранее я обнаружил, что загрузка ЦП была низкой, я думал, что шифр по умолчанию может быть слишком интенсивным, чтобы система не отставала от него. Поэтому я добавил cipher RC2-40-CBCоба конфига (очень легкий шифр) и перезапустил OpenVPN. Без улучшения.
3. Я читал на различных форумах о том, как настройка фрагмента, mssfix и mtu-tun может помочь с производительностью. Я играл с несколькими вариантами, как описано в этой статье , но, опять же, без улучшений.
Любые идеи о том, что может быть причиной такой низкой производительности OpenVPN?
cipher noneхотя я сомневаюсь, что это поможет.Ответы:
После большого количества настроек Google и настроек я нашел решение. Сейчас у меня стабильная скорость 60 Мбит / с и скорость до 80 Мбит / с. Это немного медленнее, чем скорость передачи, которую я получаю за пределами VPN, но я думаю, что это так же хорошо, как и получится.
Первым шагом была настройка
sndbuf 0иrcvbuf 0в конфигурации OpenVPN как для сервера, так и для клиента.Я внес это изменение, увидев предложение сделать это в общедоступном посте на форуме (который является переводом на русский язык оригинального поста на русском языке ), который я процитирую здесь:
Далее автор описывает, как передать клиенту настройки размера буфера, если вы сами не управляете конфигурацией клиента.
После того, как я внес эти изменения, моя пропускная способность возросла до 20 Мбит / с. Затем я увидел, что загрузка ЦП на одном ядре была немного высокой, поэтому я удалил
comp-lzo(сжатие) из конфигурации как на клиенте, так и на сервере. Эврика! Скорость передачи данных выросла до 60 Мбит / с, а скорость 80 Мбит / с.Я надеюсь, что это поможет кому-то решить свои проблемы с медлительностью OpenVPN!
источник
После нескольких попыток я нашел хорошее решение. В моем случае ответ @ Elliot не помог. Погуглив больше, я обнаружил этот фрагмент, чтобы добавить в конфигурацию сервера, который сделал работу
У меня есть небольшой сервер OpenVPN, работающий на Raspberry PI3, и теперь я получаю нисходящую линию связи 71 Мбит / с и восходящую линию связи 16 Мбит / с . Загрузка ограничена, так как мощность процессора. Прямо сейчас моя конфигурация следующая:
OpenVPN 2.4.0 arm-unknown-linux-gnueabihf с OpenSSL 1.0.2l
Это настолько странно, что такая проблема с настройкой буфера по умолчанию все еще существует.
[РЕДАКТИРОВАТЬ] Мой файл client.ovpn имеет следующую структуру:
источник
В соответствии с конфигурацией вы используете TCP в качестве транспорта для туннеля. Подумайте об использовании UDP вместо TCP, так как стекированные соединения TCP-палатки создают проблемы в ситуациях потери пакетов.
В качестве ссылки смотрите, почему TCP через TCP - плохая идея
источник
We need to ensure that the data packets we transmit arrive as expected.и разве это не обрабатывается протоколом, который туннелируется? Как вы думаете, почему ваш туннель должен обеспечивать это?У нас есть два межконтинентальных сервера, которые связаны друг с другом, скорость между ними колеблется около 220 Мбит / с.
Однако в туннеле (UDP) OpenVPN скорость будет в среднем 21 Мбит / с - примерно в 10 раз медленнее.
(Между серверами существует значительная задержка: около 130 мс, и передачи измерялись с помощью Iperf3 в режиме TCP.)
Перепробовал все предложения по ответам здесь на момент написания статьи, и ничего не помогло.
Единственное, что в итоге помогло, это немного:
Согласно справочному руководству OpenVPN:
После установки этого параметра на сервере и клиенте я смог достичь тех же скоростей прямого соединения (~ 250 Мбит / с) также в туннеле OpenVPN.
Я уже использовал
rcvbuf 0иsndbuf 0, но, по крайней мере, один , они не помогли вообще.Я нашел эти рекомендации как на этой странице на форумах OpenVPN , так и на этой странице в вики UDPspeeder .
С другой стороны: мне удалось достичь более высоких скоростей, используя UDP-передачу в iperf, но это также повлекло бы за собой достаточно высокую потерю пакетов.
Если по какой-то причине вам понадобится использовать VPN для туннелирования в двух местах с потерями, я бы посоветовал рассмотреть возможность использования своего рода туннеля прямого исправления ошибок (FEC) под самой VPN. Два из них мне удалось найти и работать с:
И то, и другое может сильно помочь с потерей пакетов (прежде всего, потратив больше пропускной способности) и, в конечном итоге, даже привести к более высокой пропускной способности данных, даже с дополнительными издержками, что очень удобно, если вы спросите меня.
(Это потому, что потеря пакетов может действительно испортить сеть , особенно TCP . См. Стр. 6.)
Я бы предпочел использовать OpenVPN в UDP по всем обычным причинам, но мне было трудно иметь дело с UDPspeeder, когда у вас есть задержка более 100 мс и скорость> 10 Мбит / с.
kcptun однако, работал большой с очень небольшой настройки, и на самом деле действительно увеличили наши серверы пропускной способности друг с другом. знак равно
В расширенной заметке, здесь вы можете найти более подробные объяснения о настройке некоторых частей производительности OpenVPN.
источник
Для меня у меня был VPS-сервер с настройкой openvpn-сервера в Японии, и мое клиентское соединение использовало DDWRT в режиме клиента OpenVPN в Нью-Йорке. Я получал только 1-2 Мбит / с при соединении 100 Мбит. Лучшее, что я смог оптимизировать для этого, было 5 Мбит / с, чего было достаточно для того, что мне было нужно, и это было настолько оптимизировано, насколько я могу, я верю.
Настройки моего OpenVPN сервера:
Мои настройки клиента DDWRT OpenVPN также видны на моем скриншоте:
источник