OpenVPN basse performance. Ai-je des problèmes de MTU? Dumps à l'intérieur

J'ai des problèmes avec un tunnel OpenVPN qui n'atteint pas la vitesse de ligne. La passerelle est un serveur virtuel Debian Jessy hébergé chez OVH. Le client est soit mon serveur domestique freebsd 10.2 (Intel I3 Ivy Bridge) ou mon RaspberryPI2. J'ai désactivé le cryptage et l'authentification. J'ai une connexion FTTH symétrique de 100 Mbits / s mais le tunnel n'atteint qu'une vitesse de 20 à 40 Mbits / s. La connexion directe (sans tunnel) donne toujours les 100 Mbits / s que j'attends. J'ai testé les performances avec iperf3. J'ai d'abord essayé avec mon serveur domestique freebsd. J'ai essayé tous les paramètres recommandés sur mssfix, fragment etc. Rien n'y fait.

Ensuite, j'ai pensé que c'était peut-être ma machine freebsd. J'ai donc installé une nouvelle raspbian Jessy sur mon RPI2 et j'ai fait des tests plus approfondis:

Tout d'abord, j'ai supprimé tous les paramètres MTU des configurations OpenVPN et laissé le chemin MTU gérer les choses (avec un peu de chance). Comme je n'ai pas de pare-feu actif sur les deux machines, cela devrait fonctionner. Ce sont mes configs 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

Tout d'abord le test sans tunnel pour montrer que la connexion au serveur est en effet de près de 100 Mbits / s:

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.

Les paquets de cette connexion ont été vidés avec tcpdump sur le serveur. Vous pouvez les télécharger ici (vous devez les extraire pour les ouvrir avec Wireshark): dumpraw.cap.xz

Voici à quoi ressemble un vidage "OK". La taille maximale du cadre que j'ai repéré est de 1514.

Maintenant, j'ai exécuté le test sur le tunnel:

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.

Oups. Plus si gentil. Surtout cette colonne "Retr" n'a pas l'air si bien. J'ai supposé qu'il s'agissait de la retransmission TCP et qu'il devrait y avoir alors quelque chose dans le vidage. Nous verrons que ce n'est pas le cas: /. Le CPU n'est pas le goulot d'étranglement ici parce que j'ai désactivé l'inscription et l'authentification. Le CPU est à 20% sur le serveur et 50% sur le PI pendant le test.

Voici à quoi ressemble le trafic OpenVPN du test:

Pour moi, cela semble correct. Mais je ne sais pas quoi chercher. Veuillez jeter un œil au vidage avec Wireshark: dump_physical.cap.xz

Le trafic sur l'interface du tunnel me semble également bon. Il semble qu'il ait correctement réduit la taille du cadre (à 1444 comme il semble):

Voici le vidage: dump_tunnel.cap.xz

Pour moi, cela semble très bien, mais je ne sais vraiment pas quoi chercher exactement. J'ai vraiment tout testé avec les paramètres OpenVPN. Peut-être que quelqu'un peut me dire si le trafic semble correct.

Ce que j'attends comme réponse

Au moins une explication de ce qui se passe ici et pourquoi il semble être indépendant du logiciel VPN que j'utilise. Tout ce que j'ai trouvé sur Internet concernait des problèmes de MTU, mais cela devrait être facilement résolu en réduisant le tunnel MTU ou les autres paramètres d'OpenVPN. Pour moi, cela change peu. Lorsque vous regardez le vidage, vous voyez qu'il réduit la taille du segment TCP et que les paquets ne sont pas fragmentés. Il doit y avoir autre chose. J'aime vraiment savoir quoi .

Mise à jour

J'ai testé cela avec strongswan et même avec softether. C'est en fait le même problème (vitesse comparable, pas de goulot d'étranglement du processeur). Je suis vraiment perplexe quel est le problème ici. J'ai également essayé une autre passerelle (RaspberryPi2 sur la connexion à domicile d'amis 100/100).

Update 2

J'ai remarqué que iperf3 signale des retransmissions TCP (retr) mais il n'y a pas de retransmissions dans le vidage (Wireshark devrait les mettre en surbrillance). Que se passe-t-il?

J'ai même essayé OpenVPN sur mon réseau local (RaspberryPi2 à FreebsdServer). Même là, j'ai beaucoup de retransmissions (sur 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

En mode inverse, j'ai une fenêtre de congestion vraiment bizarre (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

Mise à jour 3

L'utilisation d'iperf avec udp entraîne un blocage temporaire de ce port (ils m'envoient un e-mail m'informant d'une attaque) et une perte massive de paquets:

-----------------------------------------------------------
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

— Alexander Theißen
source

Si vous ne l'avez pas encore fait, vous pouvez l'essayer: tun-mtu 9000 fragment 0 mssfix 0(les options doivent être ajoutées sur trois lignes différentes)

— Diamant

J'ai déjà testé ça. Mais j'ai testé à nouveau. Ce qui s'est passé, c'est qu'il démarre à la même vitesse mais que les connexions s'arrêtent. Ce qui arrive d'ailleurs quand je désactive la fragmentation des paquets OpenVPN. Ce guide community.openvpn.net/openvpn/wiki/Gigabit_Networks vous fait penser que le système d'exploitation devrait le gérer, mais ce n'est évidemment pas le cas.

— Alexander Theißen

Oh wow. Je vois exactement le même comportement sur mes VPN, et j'ai du matériel costaud aux deux extrémités et une connexion Internet plus lente. Je vais enquêter davantage; si je trouve quelque chose de concret, je posterai ici.

— Harald

Si je passe mon test en UDP (iperf3 -u -b 25m), j'obtiens la pleine vitesse à l'intérieur et à l'extérieur du tunnel openvpn. J'ai confirmé qu'il n'y a pas de fragmentation lors de l'utilisation de TCP - openvpn signale correctement un petit MSS, mes paquets tcp à l'intérieur du tunnel sont tous de 1354 octets et les paquets UDP arrivent sans fragmentation. Je vois le même phénomène que vous - les valeurs CWND à l'intérieur du tunnel sont environ la moitié de ce qu'elles sont à l'extérieur du tunnel, et le débit est également la moitié, mais je ne peux pas expliquer pourquoi . Fascinant.

— Harald

D'accord, mes excuses pour avoir créé un faux espoir. En essayant d'éliminer tout un tas de variables, j'ai installé un OpenVPN avec les mêmes paramètres de configuration, fonctionnant sur mon LAN local. En dehors du tunnel, 750 Mbps. À l'intérieur du tunnel, 117 Mbps. Mais - openvpn consommait 100% d'un seul cœur de processeur sur les deux points de terminaison. Alors j'ai déplacé le point de terminaison domestique de mon tunnel Internet vers un "vrai" serveur et j'ai vu les 25 Mbps attendus à travers mon tunnel. OpenVPN sur les deux points de terminaison consommait environ 20% de CPU. Pour faire court - dans mon cas, le problème est que mon point de terminaison de tunnel côté maison est lié au processeur. Pardon!

— Harald

Pour commencer, votre exécution iperf du tunnel extérieur «normal» doit être UDP / 1194 comme flux sur lequel vous avez le problème et non TCP / 5201. Essayez d'abord avec -b 100M, mais gardez à l'esprit que cela produira des datagrammes de taille maximale qui ne sont pas représentatifs de votre trafic VPN (la taille du datagramme doit être en quelque sorte aléatoire). Ajustez avec l'option -l pour la taille du datagramme et vérifiez les résultats. Si les résultats ne sont pas bons (je dirais> 15 ou 20% de perte), vous pouvez soupçonner un routeur Internet surchargé qui abandonne vos paquets (probablement marqués au mieux).

En outre, il pourrait être intéressant de voir les performances que vous obtenez si vous basculez votre tunnel VPN sur un port UDP de classe EF (je dirais 5061 en raison de RTP, mais pas vraiment sûr que tous les routeurs Internet ont correctement configuré la QoS) ou tout autre Port TCP.

Pour moi, il n'y a rien de mal avec votre configuration et vos diagnostics ne montrent rien d'étrange. Essayez également une autre version d'OpenVPN ou d'un autre logiciel VPN.

— 30gd4n
source

Fait ça. Regardez update3. Attendre ovh pour débloquer le port pour effectuer d'autres tests.

— Alexander Theißen

Aww, désolé, je n'ai pas vu cette dernière mise à jour. En attendant OVH essayez de monter votre VPN sur TCP; quels résultats? Également sur votre deuxième montage et la retransmission de * BSD vers PI; avez-vous joué avec les tampons serveur d'iperf? C'est 8 Ko par défaut, je ne sais pas comment la pile est faite sur ARM et Linux mais je pense que l'augmentation pourrait aider.

— 30gd4n

Je voulais dire que je l'ai ajouté après que vous m'ayez dit :). Les résultats sur tcp sont pires. Le TCP 443 ne fait aucune différence. Le plus drôle, c'est que lorsque j'utilise ce github.com/sivel/speedtest-cli pour le tester, il signale 95 m de descente et 75 m de hauteur. Je fais plus confiance à iperf mais cela dépend vraiment du type de trafic, semble-t-il. Playstation4 prend également plus de temps pour télécharger des jeux ou des correctifs sur le tunnel. À la maison, je ferai un tunnel directement entre deux Rbps qui sont à des endroits différents mais utilisent le même FAI. Je l'ai fait avant et les résultats étaient presque les mêmes. Mais j'essaie de faire d'autres tests.

— Alexander Theißen