OpenVPN низька продуктивність. Чи є у мене проблеми з MTU? Звалиться всередині

У мене проблеми з тунелем OpenVPN, який не досягає швидкості лінії. Шлюз - це віртуальний сервер Debian Jessy, розміщений в OVH. Клієнт - це мій домашній сервер freebsd 10.2 (Intel I3 Ivy Bridge) або мій RaspberryPI2. Я відключив шифрування та автентифікацію. У мене симметричне FTTH-з'єднання 100 Мбіт / с, але тунель досягає швидкості лише 20-40 Мбіт / с. Пряме підключення (без тунелю) завжди дає очікувані 100 мбіт / с. Я перевірив продуктивність за допомогою iperf3. Я спершу спробував зі своїм домашнім сервером freebsd. Я спробував усі рекомендовані параметри щодо 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 на сервер. Ви можете завантажити їх тут (вам потрібно витягнути, щоб відкрити їх за допомогою дроту ): 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, і тоді має бути щось на смітнику. Ми побачимо, що це не так: /. ЦП тут не є вузьким місцем, оскільки я деактивував шифрування та автентифікацію. CPU становить 20% на сервері та 50% на PI під час тесту.

Ось так виглядає трафік OpenVPN тесту:

Для мене це виглядає нормально. Але я не знаю, що шукати. Будь ласка, подивіться на звалище з проводками : dump_physical.cap.xz

Трафік на інтерфейсі тунелю також мені добре виглядає. Схоже, він правильно зменшив розмір кадру (до 1444, як здається):

Ось дамп: dump_tunnel.cap.xz

Для мене це виглядає все добре, але я дійсно не маю уявлення, що саме шукати. Я дійсно все випробував за допомогою налаштувань OpenVPN. Можливо, хтось може мені сказати, якщо трафік виглядає нормально.

Що я очікую як відповідь

Принаймні пояснення того, що тут відбувається, і чому воно, здається, не залежить від програмного забезпечення VPN, яке я використовую. Все, що я знайшов в Інтернеті, стосувався проблем MTU, але це слід легко виправити, зменшивши тунельний MTU або інші параметри OpenVPN. Для мене це мало змінюється. Переглядаючи дамп, ви бачите, що він зменшує розмір сегмента tcp і пакети не фрагментовані. Має бути щось інше. Мені дуже подобається знати, що .

Оновлення

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

Оновлення 2

Я помітив, що iperf3 повідомляє tcp retransmite (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

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

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

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