☰

Исправление снижения скорости передачи данных на 70% через VPN по сравнению с SSH? (Протестировано OpenVPN, IPSec/L2TP, OpenSSH, SoftEther)

tag-icon • tag-icon vpn openvpn ipsec bandwidth site-to-site-vpn
Исправление снижения скорости передачи данных на 70% через VPN по сравнению с SSH? (Протестировано OpenVPN, IPSec/L2TP, OpenSSH, SoftEther)

В настоящее время я настраиваю site-to-site VPN между двумя VPS, который требует как исходящих, так и входящих соединений. Он будет использоваться приложением с высокой пропускной способностью, поэтому мне требуется максимальная скорость, которую я могу получить через соединение.

Используя iperf3, я получаю около 600 Мбит/с по надежному соединению с пингом около 30 мс.

Через OpenSSH SCP я получаю около 260 Мбит/с, что меня вполне устраивает, учитывая дополнительное шифрование.

Я пробовал разные конфигурации VPN, в основном с OpenVPN. Я пробовал менять sndbuf/rcvbuf, без шифрования, без сжатия, но я все равно получаю только 20 Мбит с UDP, 40 Мбит с TLS на порту 443.

Я также настроил IPSec/L2TP, SoftEther (хотя с этим я получил только 500 Кбит/с) и встроенный адаптер OpenSSH Tun. Ни один из них не смог дать мне скорость iperf выше 40 Мбит/с.

Я внимательно следил за HDD и CPU каждого узла, и ни один из них не был перегружен. Один сервер значительно менее мощный, но во время теста он достигает только ~30% использования CPU.

Я немного в растерянности. Мне нужно что-то, что может достигать скоростей выше 200 Мбит/с (что, я точно знаю, возможно), и просто маршрутизировать с одного виртуального интерфейса на другой. Теоретически, для этого и нужен SoftEther. Стоит ли мне продолжать пытаться исправить SoftEther, чтобы получить хоть какую-то реальную скорость?

Есть ли предложения по дополнительным аспектам для тестирования/отладки/настройки, чтобы попытаться получить надежный туннельный интерфейс и работать? Есть ли еще какое-нибудь программное обеспечение, которое поможет маршрутизировать входящие соединения, чтобы я мог использовать обычный туннель типа прокси? Спасибо!

решение1

Учитывая ссылку, размещенную в комментариях, я решил еще раз взглянуть на эту статью OpenVPN: https://community.openvpn.net/openvpn/wiki/Гигабитные_Сети_Linux

Мне удалось достичь ~150Mbit/s в среднем, используя пару настроек из этой статьи. Вот шаги, которые я предпринял для настройки OpenVPN, чтобы достичь этого.

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

  • Настройки по умолчанию (с AES-128): 14,7 Мбит/с
  • Включить mssfix 0, tun-mtu 6000, фрагмент 0: 16.3Mbit/s
  • Настройка «без шифрования»: 17,7 Мбит/с
  • Возвращаемся к AES-128, tun-mtu 9000: 22,0 Мбит/с
  • tun-mtu 18000: 27,2 Мбит/с
  • tun-mtu 36000: 37,2 Мбит/с
  • tun-mtu 60000: 44,9 Мбит/с
  • Настройка «шифр BF-CBC» (большой разницы нет): 44,0 Мбит/с
  • sndbuf 393216, rcvbuf 393216 на сервере и клиенте: 67,1 Мбит/с
  • Увеличенный размер буферов Linux UDP Recv: 102Мбит/с
  • iperf3 [...] -P 10 для включения 10 параллельных подключений: СУММА:135Мбит/с - 170Мбит/с

Вот окончательный вывод iperf3:

64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=37.2 ms

$ iperf3 -c 10.8.0.1 -p 5201
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.2 port 59230 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.3 MBytes  86.5 Mbits/sec    2    632 KBytes
[  4]   1.00-2.00   sec  12.0 MBytes   101 Mbits/sec    7    569 KBytes
[  4]   2.00-3.00   sec  11.4 MBytes  95.8 Mbits/sec    7    443 KBytes
[  4]   3.00-4.00   sec  10.9 MBytes  91.2 Mbits/sec    5    443 KBytes
[  4]   4.00-5.00   sec  11.7 MBytes  98.4 Mbits/sec    2    759 KBytes
[  4]   5.00-6.00   sec  13.0 MBytes   109 Mbits/sec    6    822 KBytes
[  4]   6.00-7.00   sec  13.5 MBytes   113 Mbits/sec    5    696 KBytes
[  4]   7.00-8.00   sec  13.9 MBytes   117 Mbits/sec    6    696 KBytes
[  4]   8.00-9.00   sec  11.8 MBytes  98.9 Mbits/sec    5    696 KBytes
[  4]   9.00-10.00  sec  12.5 MBytes   105 Mbits/sec    4    696 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   121 MBytes   102 Mbits/sec   49             sender
[  4]   0.00-10.00  sec   120 MBytes   101 Mbits/sec                  receiver

По сравнению с прямым подключением без VPN:

$ iperf3 -c [...] -p 5201
Connecting to host [...], port 5201
[  4] local [...] port 52172 connected to [...] port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  51.9 MBytes   435 Mbits/sec    0   3.03 MBytes
[  4]   1.00-2.00   sec  73.3 MBytes   615 Mbits/sec    0   3.03 MBytes
[  4]   2.00-3.00   sec  73.3 MBytes   615 Mbits/sec    0   3.03 MBytes
[  4]   3.00-4.00   sec  72.7 MBytes   610 Mbits/sec    0   3.03 MBytes
[  4]   4.00-5.00   sec  72.1 MBytes   605 Mbits/sec    0   3.03 MBytes
[  4]   5.00-6.00   sec  73.7 MBytes   619 Mbits/sec    0   3.03 MBytes
[  4]   6.00-7.00   sec  75.0 MBytes   629 Mbits/sec    0   3.03 MBytes
[  4]   7.00-8.00   sec  72.5 MBytes   608 Mbits/sec    0   3.03 MBytes
[  4]   8.00-9.00   sec  74.9 MBytes   628 Mbits/sec    0   3.03 MBytes
[  4]   9.00-10.00  sec  72.6 MBytes   609 Mbits/sec    0   3.03 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   712 MBytes   597 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   710 MBytes   596 Mbits/sec                  receiver

Что я выучил

  • Моя сеть значительно выиграла от увеличения tun-mtu.
  • Перегрузка UDP — огромная проблема. Увеличение Linux UDP recvbuf значительно улучшило производительность UDP. Повторно переданные пакеты в iperf показывают, что перегрузка все еще остается проблемой.Любые предложения по улучшению приветствуются.
  • Параллельные соединения iperf3 помогли еще больше увеличить скорость.
  • Шифры не оказывали существенного влияния на производительность, пока загрузка ядра ЦП оставалась ниже 100%.
  • Сложно настроить VPN через открытый Интернет, который бы достигал гигабитных скоростей.
  • Это все еще составляет 1/6 от производительности обычной сети.

Связанный контент