Низкая производительность OpenVPN. У меня проблемы с MTU? Свалки внутри
У меня проблемы с туннелем OpenVPN, который не достигает скорости линии. Шлюз - это виртуальный сервер Debian Jessy, размещенный в OVH. Клиент - это либо мой домашний сервер freebsd 10.2 (Intel I3 Ivy Bridge), либо мой RaspberryPI2. Я отключил шифрование и аутентификацию. У меня симметричное соединение FTTH 100 Мбит / с, но туннель достигает скорости только 20-40 Мбит / с. Прямое соединение (без туннеля) всегда дает ожидаемые 100 Мбит / с. Я тестировал производительность с iperf3. Я сначала попробовал с моим домашним сервером freebsd. Я перепробовал все рекомендуемые настройки для mssfix, fragment и т.д. Ничего не помогло.
Потом подумал, может, это моя машина с freebsd. Итак, я установил свежий raspbian Jessy на свой 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 на сервер. Вы можете скачать их здесь (вам нужно извлечь их, чтобы открыть с помощью wirehark): dumpraw.cap.xz
Вот так выглядит дамп "ОК". Максимальный размер кадра, который я заметил, - 1514. 
Теперь я провел тест по туннелю:
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%, а на PI - 50%.
Вот так выглядит OpenVPN-трафик теста: 
На мой взгляд, это нормально. Но я не знаю, что искать. Взгляните, пожалуйста, на дамп с wirehark: dump_physical.cap.xz
Трафик на туннельном интерфейсе мне тоже нравится. Вроде правильно уменьшил размер кадра (как кажется до 1444): 
Вот дамп: dump_tunnel.cap.xz
На мой взгляд, это все нормально, но я действительно понятия не имею, что именно искать. Я действительно все проверил с настройками OpenVPN. Может, кто-нибудь скажет мне, нормальный ли трафик.
Чего я жду в качестве ответа
По крайней мере, объяснение того, что здесь происходит и почему это кажется независимым от программного обеспечения VPN, которое я использую. Все, что я нашел в Интернете, касалось проблем с MTU, но это должно быть легко исправлено путем уменьшения MTU туннеля или других параметров OpenVPN. Для меня это мало что меняет. Когда вы смотрите на дамп, вы видите, что он уменьшает размер сегмента tcp и пакеты не фрагментируются. Должно быть что-то еще. Мне очень нравится знать какие.
Обновить
Я тестировал это на Strongswan и даже на softtether. Фактически это та же проблема (сопоставимая скорость, отсутствие узких мест в процессоре). Я действительно озадачен, в чем проблема. Я также пробовал другой шлюз (RaspberryPi2 на домашнем подключении 100/100 друзей).
Обновление 2
Я заметил, что iperf3 сообщает о повторных передачах tcp (retr), но в дампе нет повторных передач (Wireshark должен их выделить). Что происходит?
Я даже пробовал OpenVPN в своей локальной сети (от RaspberryPi2 до FreebsdServer). Даже там у меня много ретрансмитов (по LAN ?!):
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
В обратном режиме у меня действительно странное окно перегрузки (что за?):
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 приводит к временной блокировке этого порта ovh (они отправляют мне электронное письмо, информирующее меня об атаке) и массовой потере пакетов:
-----------------------------------------------------------
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
Во-первых, ваш «нормальный» внешний туннель iperf запускается как поток UDP / 1194, а не TCP / 5201. Сначала попробуйте использовать -b 100M, но имейте в виду, что при этом будут получены датаграммы максимального размера, которые не являются репрезентативными для вашего VPN-трафика (размер датаграммы должен быть случайным). Настройтесь с параметром -l для размера дейтаграммы и проверьте результаты. Если результаты не очень хороши (я бы сказал, потеря> 15 или 20%), вы можете подозревать перегруженный интернет-маршрутизатор, который отбрасывает ваши (вероятно, отмеченные как наилучшие) пакеты.
Кроме того, может быть интересно посмотреть, какую производительность вы получите, если переключите свой VPN-туннель либо на порт UDP класса EF (я бы сказал, что 5061 из-за RTP, но не совсем уверен, что все интернет-маршрутизаторы правильно настроили QoS) или любой другой TCP-порт.
На мой взгляд, в вашей настройке нет ничего плохого, и ваша диагностика не показывает ничего странного. Также попробуйте другую версию OpenVPN или другое программное обеспечение VPN.