OpenVPN низкая производительность. У меня проблемы с MTU? Отвалы внутри

13

У меня проблемы с туннелем OpenVPN, который не достигает скорости линии. Шлюз - это виртуальный сервер Debian Jessy, размещенный в OVH. Клиент - это либо мой домашний сервер freebsd 10.2 (Intel I3 Ivy Bridge), либо мой RaspberryPI2. Я деактивировал шифрование и аутентификацию. У меня симметричное соединение FTTH со скоростью 100 Мбит / с, но скорость туннеля достигает только 20-40 Мбит / с. Прямое соединение (без туннеля) всегда дает ожидаемые 100 Мбит / с. Я проверил производительность с iperf3. Я сначала попробовал с моим freebsd homeserver. Я перепробовал все рекомендуемые настройки, касающиеся mssfix, фрагмента и т. Д. Ничего не помогло.

Тогда я подумал, может быть, это моя машина freebsd. Поэтому я установил свежую распсианку Джесси на свой RPI2 и провел еще несколько углубленных тестов:

Первым делом я удалил все настройки MTU из конфигов OpenVPN и позволил пути MTU обрабатывать вещи (надеюсь). Поскольку на обеих машинах у меня нет активного брандмауэра, он должен работать. Это мои vpn конфиги:

server 10.8.0.0 255.255.255.0
port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0

user nobody
group nogroup
persist-key
persist-tun
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1"
status openvpn-status.log
verb 3

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/vpn.theissen.io.crt
key /etc/openvpn/easy-rsa/keys/vpn.theissen.io.key
dh /etc/openvpn/easy-rsa/keys/dh4096.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher none
auth none
comp-lzo no



client
proto udp
dev tun12
remote xxx.io 1194
resolv-retry infinite
sndbuf 0
rcvbuf 0

nobind
user nobody
group nogroup
persist-key
persist-tun
verb 3

pkcs12 /etc/openvpn/vpn.theissen.io/alex.p12
tls-auth /etc/openvpn/vpn.theissen.io/ta.key 1
ns-cert-type server
cipher none
auth none
comp-lzo no

Прежде всего, тест без туннеля, чтобы показать, что соединение с сервером действительно почти 100 Мбит / с:

iperf3 -c vpn.theissen.io
Connecting to host vpn.theissen.io, port 5201
[  4] local 192.168.1.253 port 34512 connected to 149.202.58.183 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  10.8 MBytes  90.5 Mbits/sec    0    335 KBytes       
[  4]   1.00-2.00   sec  11.4 MBytes  95.7 Mbits/sec    0    335 KBytes       
[  4]   2.00-3.00   sec  11.1 MBytes  93.0 Mbits/sec    0    352 KBytes       
[  4]   3.00-4.00   sec  11.2 MBytes  94.0 Mbits/sec    0    369 KBytes       
[  4]   4.00-5.00   sec  11.5 MBytes  95.9 Mbits/sec    0    390 KBytes       
[  4]   5.00-6.00   sec  11.0 MBytes  92.5 Mbits/sec    0    390 KBytes       
[  4]   6.00-7.00   sec  11.4 MBytes  95.2 Mbits/sec    0    390 KBytes       
[  4]   7.00-8.00   sec  11.2 MBytes  94.3 Mbits/sec    0    390 KBytes       
[  4]   8.00-9.00   sec  11.1 MBytes  93.3 Mbits/sec    0    390 KBytes       
[  4]   9.00-10.00  sec  11.3 MBytes  95.1 Mbits/sec    0    390 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  93.9 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   112 MBytes  93.5 Mbits/sec                  receiver

iperf Done.

Пакеты этого соединения я сбросил с помощью tcpdump на сервере. Вы можете скачать их здесь (вы должны извлечь их, чтобы открыть wireshark): dumpraw.cap.xz

Вот так выглядит дамп «ОК». Максимальный размер кадра, который я заметил, составляет 1514. Отвал iperf3 без туннеля

Теперь я провел тест по туннелю:

iperf3 -c 10.8.0.1
Connecting to host 10.8.0.1, port 5201
[  4] local 10.8.0.14 port 36388 connected to 10.8.0.1 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  5.96 MBytes  50.0 Mbits/sec  127    133 KBytes       
[  4]   1.00-2.00   sec  5.19 MBytes  43.5 Mbits/sec    6    120 KBytes       
[  4]   2.00-3.00   sec  5.80 MBytes  48.7 Mbits/sec    0    151 KBytes       
[  4]   3.00-4.00   sec  4.27 MBytes  35.9 Mbits/sec   23   96.5 KBytes       
[  4]   4.00-5.00   sec  4.89 MBytes  41.0 Mbits/sec    0    129 KBytes       
[  4]   5.00-6.00   sec  6.11 MBytes  51.2 Mbits/sec   26    111 KBytes       
[  4]   6.00-7.00   sec  5.50 MBytes  46.1 Mbits/sec    0    143 KBytes       
[  4]   7.00-8.00   sec  5.25 MBytes  44.1 Mbits/sec   15    126 KBytes       
[  4]   8.00-9.00   sec  5.80 MBytes  48.7 Mbits/sec    0    158 KBytes       
[  4]   9.00-10.00  sec  3.97 MBytes  33.3 Mbits/sec   22    105 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  52.7 MBytes  44.2 Mbits/sec  219             sender
[  4]   0.00-10.00  sec  52.3 MBytes  43.8 Mbits/sec                  receiver

iperf Done.

Упс. Уже не так приятно. Особенно эта колонка «Retr» выглядит не очень хорошо. Я предположил, что это ретрансляция tcp, и тогда должно быть что-то в дампе. Мы увидим, что это не так: /. Процессор здесь не является узким местом, потому что я деактивировал шифрование и аутентификацию. Процессор находится на 20% на сервере и 50% на PI во время теста.

Вот как выглядит трафик OpenVPN теста: Трафик OpenVPN на физическом интерфейсе

Для меня это выглядит хорошо. Но я не знаю, что искать. Пожалуйста, посмотрите на дамп с wireshark: dump_physical.cap.xz

Трафик на туннельном интерфейсе мне тоже нравится. Кажется, он правильно уменьшил размер кадра (до 1444, как кажется): Трафик iperf3 на туннельном интерфейсе

Вот дамп: dump_tunnel.cap.xz

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

Что я ожидаю в качестве ответа

По крайней мере, объяснение того, что здесь происходит и почему оно кажется независимым от программного обеспечения VPN, которое я использую. Все, что я обнаружил в Интернете, было о проблемах MTU, но это должно быть легко исправлено уменьшением MTU туннеля или других параметров OpenVPN. Для меня это мало что меняет. Когда вы смотрите на дамп, вы видите, что он уменьшает размер сегмента tcp и пакеты не фрагментированы. Там должно быть что-то еще. Мне действительно нравится знать что .

Обновить

Я проверил это с сильной и даже более мягкой. Это на самом деле та же проблема (сравнимая скорость, нет узких мест процессора). Я действительно озадачен, в чем здесь проблема. Я также попробовал другой шлюз (RaspberryPi2 на домашнем соединении друзей 100/100).

Обновление 2

Я заметил, что iperf3 сообщает о повторных передачах tcp (retr), но в дампе нет повторных передач (Wireshark должен выделить их). Что здесь происходит?

Я даже пробовал OpenVPN в моей локальной сети (от RaspberryPi2 до FreebsdServer). Даже там у меня много ретрансляций (по локальной сети ?!):

Connecting to host 192.168.222.11, port 5201
[  4] local 192.168.222.10 port 46196 connected to 192.168.222.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  9.19 MBytes  77.0 Mbits/sec    8    141 KBytes       
[  4]   1.00-2.00   sec  8.71 MBytes  73.1 Mbits/sec    3    130 KBytes       
[  4]   2.00-3.00   sec  8.59 MBytes  72.0 Mbits/sec    3    120 KBytes       
[  4]   3.00-4.00   sec  8.65 MBytes  72.5 Mbits/sec    4    108 KBytes       
[  4]   4.00-5.00   sec  8.65 MBytes  72.5 Mbits/sec    4   95.6 KBytes       
[  4]   5.00-6.00   sec  8.52 MBytes  71.5 Mbits/sec    2   80.5 KBytes       
[  4]   6.00-7.00   sec  8.83 MBytes  74.1 Mbits/sec    0    141 KBytes       
[  4]   7.00-8.00   sec  8.59 MBytes  72.0 Mbits/sec    7    106 KBytes       
[  4]   8.00-9.00   sec  8.71 MBytes  73.1 Mbits/sec    3   94.2 KBytes       
[  4]   9.00-10.00  sec  8.59 MBytes  72.0 Mbits/sec    3   79.2 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.0 MBytes  73.0 Mbits/sec   37             sender
[  4]   0.00-10.00  sec  86.8 MBytes  72.8 Mbits/sec                  receiver

В обратном режиме у меня действительно странное окно затора (wtf?):

Accepted connection from 192.168.222.10, port 46197
[  5] local 192.168.222.11 port 5201 connected to 192.168.222.10 port 46198
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec  8.90 MBytes  74.7 Mbits/sec    3   1.48 GBytes       
[  5]   1.00-2.00   sec  8.45 MBytes  70.9 Mbits/sec    2   1.59 GBytes       
[  5]   2.00-3.00   sec  8.66 MBytes  72.7 Mbits/sec  518    214 MBytes       
[  5]   3.00-4.00   sec  7.96 MBytes  66.8 Mbits/sec   37    703 MBytes       
[  5]   4.00-5.00   sec  8.09 MBytes  67.9 Mbits/sec    0    719 MBytes       
[  5]   5.00-6.00   sec  8.04 MBytes  67.5 Mbits/sec    0    734 MBytes       
[  5]   6.00-7.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   7.00-8.00   sec  8.07 MBytes  67.7 Mbits/sec    1    703 MBytes       
[  5]   8.00-9.00   sec  7.99 MBytes  67.1 Mbits/sec    2    693 MBytes       
[  5]   9.00-10.00  sec  8.06 MBytes  67.6 Mbits/sec    1    693 MBytes       
[  5]  10.00-10.09  sec   684 KBytes  64.5 Mbits/sec    0    695 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.09  sec  83.0 MBytes  69.0 Mbits/sec  565             sender
[  5]   0.00-10.09  sec  0.00 Bytes  0.00 bits/sec                  receiver

Обновление 3

Использование iperf с udp приводит к временной блокировке этого порта (они отправляют мне электронное письмо с информацией об атаке) и значительной потере пакетов:

-----------------------------------------------------------
Server listening on 1194
-----------------------------------------------------------
Accepted connection from 185.22.143.160, port 15906
[  5] local 149.202.58.183 port 1194 connected to 185.22.143.160 port 4355
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  2.89 MBytes  24.2 Mbits/sec  0.727 ms  1017/1387 (73%)  
iperf3: OUT OF ORDER - incoming packet = 1409 and received packet = 1470 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1410 and received packet = 1471 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1411 and received packet = 1472 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1445 and received packet = 1473 AND SP = 5
iperf3: OUT OF ORDER - incoming packet = 1463 and received packet = 1473 AND SP = 5
[  5]   1.00-2.00   sec  3.29 MBytes  27.6 Mbits/sec  0.716 ms  1110/1526 (73%)  
[  5]   2.00-3.00   sec  3.30 MBytes  27.7 Mbits/sec  0.732 ms  1103/1526 (72%)  
[  5]   3.00-4.00   sec  3.27 MBytes  27.4 Mbits/sec  0.717 ms  1108/1526 (73%)  
[  5]   4.00-5.00   sec  1.56 MBytes  13.1 Mbits/sec  0.837 ms  546/746 (73%)  
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
[  5]  10.00-10.06  sec  0.00 Bytes  0.00 bits/sec  0.837 ms  0/0 (-nan%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.06  sec   118 MBytes  98.5 Mbits/sec  0.837 ms  4884/6711 (73%)  
[SUM]  0.0-10.1 sec  4884 datagrams received out-of-order
vpn performance openvpn mtu Александр Тайсен
источник
1
Если вы еще этого не сделали, вы можете попробовать: tun-mtu 9000 fragment 0 mssfix 0(опции должны быть добавлены в трех разных строках)
Diamant
Я уже проверял это. Но я снова проверил. То, что случилось, - то, что это начинается с той же самой скоростью, но затем соединения прекращаются. Что, кстати, всегда происходит, когда я отключаю фрагментацию пакетов OpenVPN. Это руководство community.openvpn.net/openvpn/wiki/Gigabit_Networks заставляет вас думать, что ОС должна справиться с этим, но, очевидно, это не так.
Александр Тейсен
Ух ты. Я наблюдаю точно такое же поведение в своих VPN, и у меня на обоих концах мощное оборудование и более медленное интернет-соединение. Я собираюсь исследовать дальше; если я найду что-то конкретное, я отправлю сюда.
Харальд
1
Если я переключу свой тест на UDP (iperf3 -u -b 25m), я получу полную скорость как внутри, так и снаружи туннеля openvpn. Я подтвердил, что при использовании TCP нет фрагментации - openvpn правильно сообщает о небольшом MSS, все мои tcp-пакеты внутри туннеля занимают 1354 байта, а UDP-пакеты приходят не фрагментированными. Я наблюдаю то же явление, что и вы - значения CWND внутри туннеля примерно вдвое меньше, чем за пределами туннеля, и пропускная способность тоже вдвое меньше, но я не могу объяснить, почему . Захватывающий.
Харальд
1
Хорошо, мои извинения за создание ложной надежды. Пытаясь исключить целую кучу переменных, я настраиваю OpenVPN с теми же параметрами конфигурации, работающими в моей локальной сети. За пределами туннеля, 750 Мбит / с. Внутри туннеля, 117 Мбит / с. Но - openvpn потреблял 100% одного ядра процессора на обеих конечных точках. Затем я переместил домашнюю конечную точку своего интернет-туннеля на «настоящий» сервер и увидел ожидаемые 25 Мбит / с через мой туннель. OpenVPN на обеих конечных точках потреблял около 20% процессорного времени. Короче говоря, в моем случае проблема в том, что моя конечная точка домашнего туннеля связана с процессором. Сожалею!
Харальд

Ответы:

2

Для начала ваш «нормальный» запуск туннеля iperf должен быть UDP / 1194 как поток, в котором у вас возникла проблема, а не TCP / 5201. Попробуйте сначала с -b 100M, но имейте в виду, что это приведет к получению дейтаграмм максимального размера, которые не отражают ваш VPN-трафик (размер дейтаграмм должен быть как бы случайным). Настройтесь с опцией -l для размера датаграммы и проверьте результаты. Если результаты не очень хорошие (я бы сказал,> 15 или 20% потерь), вы можете заподозрить перегруженный интернет-маршрутизатор, который отбрасывает ваши (вероятно, отмеченные как наиболее эффективные) пакеты.

Кроме того, было бы интересно посмотреть, какую производительность вы получите, если переключите свой VPN-туннель либо на UDP-порт класса EF (я бы сказал, 5061 из-за RTP, но не совсем уверен, что все интернет-маршрутизаторы правильно настроили QoS), либо Порт TCP.

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

30gd4n
источник
Сделал это. Посмотри на update3. Ожидание ovh, чтобы разблокировать порт для проведения дальнейших тестов.
Александр Тиссен
Ой, извините, не видел это последнее обновление. В ожидании OVH попробуйте смонтировать VPN через TCP; Каковы результаты ? Также о вашем втором редактировании и повторной передаче из * BSD в PI; ты играл с серверными буферами iperf? Это 8 КБ по умолчанию, не знаю, как устроен стек в ARM и Linux, но я думаю, что увеличение может помочь.
30gd4n
Я имел в виду, что добавил его после того, как ты сказал мне :) Результаты по TCP хуже. Tcp 443 не имеет значения. Самое смешное, что когда я использую этот github.com/sivel/speedtest-cli для тестирования, он сообщает о 95 м вниз и 75 м вверх. Я доверяю iperf больше, но это действительно зависит от типа трафика, так что кажется. Playstation4 также занимает больше времени для загрузки игр или патчей через туннель. Когда я буду дома, я пройду туннель между двумя Rbps, которые находятся в разных местах, но используют один и тот же провайдер. Я делал это раньше, и результаты были почти такими же. Но я стараюсь делать дальнейшие тесты.
Александр Тиссен