[OpenVPN] Optimiser les débit pour connexion 1Gbps?

Support Debian
#1

Bonjour,

Voilà un certain temps que j’utilise « intensivement » OpenVPN sur différent serveurs.
Pour l’instant c’était seulement des serveurs en 100Mbps, mais j’était plus limité par le processeur que par la connexion proprement dite.

Récemment j’ai fait l’acquisition d’un nouveau serveur, avec une connectivité en 1Gbps.
Processeur Xeon E3-1230, jeux d’instruction AES (aes-ni), RAM 8Go EEC…
Sauf que maintenant ce n’est plus le processeur qui me limite, mais autre chose (Mais quoi ??? Mystère !).
En AES-256-CDC le processeur est quasiment pas sollicité (30% sur une thread).

Coté client, j’ai une connexion SFR Fibre 1Gbps.
Processeur i7-3770K, RAM 32Go… Une bonne petite bête.

Sur la machine client, comme sur la machine serveur, en download depuis Testdebit.info je suis facile au 900Mbits/s.
Et download d’un fichier du serveur (via apache) vers la machine client, idem.

En revanche, via OpenVPN, je plafonne avec les même tests à environ 160Mbps.
Si je désactive l’encryption, je tombe en dessous des 100Mbits.
Je me serais attendu pourtant à un résultat inverse.

J’ai longuement parcouru la toile.
Je suis tombé sur ça : community.openvpn.net/openvpn/w … orks_Linux
Ainsi que de nombreux forums.

Mais pas d’évolution notable dans mon cas avec les configs proposées (c’était souvent de jouer avec tun-mtu, fragment…).

Serveur :

mode server
proto udp
port 1195
dev tun0

ca keys/servers/ca.crt
cert keys/servers/server.crt
key keys/servers/server.key
dh keys/servers/dh1024.pem
tls-auth keys/ta.key 0
cipher aes-256-cbc

client-cert-not-required
username-as-common-name
plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn

server 10.1.0.0 255.255.255.0
client-config-dir others/udp-1195/
push "redirect-gateway def1 bypass-dhcp"

keepalive 10 120
persist-key
persist-tun

verb 3
status logs/udp-1195.sts
log-append logs/udp-1195.log

Client :

client
dev tun
proto udp

remote mondomaine.fr 1195

ca ca.crt
tls-auth ta.key 1
cipher AES-256-CBC

auth-user-pass ../logins.txt

nobind
resolv-retry infinite
persist-key
persist-tun
verb 3

openssl speed aes-256-cbc :

Doing aes-256 cbc for 3s on 16 size blocks: 13682966 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 64 size blocks: 3606779 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 913768 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 229469 aes-256 cbc's in 2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 28719 aes-256 cbc's in 2.99s
OpenSSL 1.0.1e 11 Feb 2013
built on: Mon Mar 18 20:41:20 CET 2013
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      73219.88k    77201.96k    77974.87k    78587.38k    78684.30k

openssl speed -evp aes-256-cbc :

Doing aes-256-cbc for 3s on 16 size blocks: 81821132 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 64 size blocks: 21479841 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 256 size blocks: 5429785 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 1361247 aes-256-cbc's in 2.99s
Doing aes-256-cbc for 3s on 8192 size blocks: 170298 aes-256-cbc's in 2.99s
OpenSSL 1.0.1e 11 Feb 2013
built on: Mon Mar 18 20:41:20 CET 2013
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc     437838.83k   459769.17k   463341.65k   466192.95k   466582.35k

Auriez-vous des pistes à me suggérer afin d’optimiser la vitesse ?
Je ne demande pas 1Gbps via OpenVPN, mais déjà 200 ou 300Mbps je serais aux anges :slightly_smiling: !

Comment font les grosses entreprises pour interconnecter plusieurs site (point-to-point, sans parler de solutions « matériel » type CISCO…) ? IPSEC, L2TP ?

Si vous avez besoin d’autre éléments, ne pas hésiter !

Merci !

#2

La charge CPU de l’autre machine ? La vitesse des disques ? Une QoS du FAI ou de l’hébergeur ?
Tu as vérifié l’absence de fragmentation des paquets à l’intérieur du tunnel et des paquets du tunnel ?

#3

CPU machine client idem, une thread, 10%.
J’ai testé sous une machine Linux, au cas où sa viendrait de l’adaptateur TAP de Windows, et ben non, c’est pareil.

Pas de problème au niveau des débits des disques, l’un comme l’autre arrivent a manger le 1Gbps sans OpenVPN.
Coté client SSD Samsung 840 Pro, coté serveur RAID 0.

QoS sa je ne sais pas.
Pas à ma connaissance en tout cas.

Pour la fragmentation, comment le vérifier ?

Merci de ta réponse PascalHambourg !

#4

Tu peux balancer ton résultat speedtest.net/

Pour faire rêver mais aussi pour voir ton upload. Merci :023

#5

Il faut lancer une capture de paquets (wireshark, tcpdump…) lors d’un téléchargement et vérifier la présence de fragments. Capturer :

  • tous les paquets sur l’interface tun/tap du VPN
  • les paquets UDP/1195 sur l’interface ethernet par laquelle passe le VPN.
#6

Serveur :

Client :

Ok. Je vais regarder.
Merci !

#7

J’arrive à capturer le trafic avec Wireshark, mais comment identifier une fragmentation ?

En revanche, quand je fais un “tcpdump -i tun0 udp port 1195” et que je met un fichier en téléchargement sur le client, rien n’est capturé. Normal ?

#8

[quote=“Darel”]Serveur :

Client :

Ok. Je vais regarder.
Merci ![/quote]

Et tu télécharges sur le serveur, depuis le client ?

#9

Non, du serveur vers le client, ou de testdebit vers le client en passant par OpenVPN.

[quote=“PascalHambourg”]Il faut lancer une capture de paquets (wireshark, tcpdump…) lors d’un téléchargement et vérifier la présence de fragments. Capturer :

  • tous les paquets sur l’interface tun/tap du VPN
  • les paquets UDP/1195 sur l’interface ethernet par laquelle passe le VPN.[/quote]
    Je penses avoir trouver comment faire avec Wireshark…

Donc je suppose que oui, sa fragmente.
C’est bien ça, ou je suis complètement à coté de la plaque ?

#10

Et si tu passes ton VPN en TCP ça donne quoi ?

#11

J’était en train de me poser la question :smiley: !
Je suis tombé sur ça : forums-web2.gentoo.org/viewtopic … art-0.html

Je vais tester.

#12

Nop, c’est encore pire, je tombe à 20Mbps.

J’ai aussi éssayer de mettre ça :

tun-mtu 6000 fragment 0 mssfix 0
Idem.

#13

[quote=“Darel”], quand je fais un “tcpdump -i tun0 udp port 1195” et que je met un fichier en téléchargement sur le client, rien n’est capturé. Normal ?
J’arrive à capturer le trafic avec Wireshark, mais comment identifier une fragmentation ?

En revanche, quand je fais un “tcpdump -i tun0 udp port 1195” et que je met un fichier en téléchargement sur le client, rien n’est capturé. Normal ?[/quote]
Oui, normal : tu n’as pas fait ce que j’ai dit dans mon message précédent. Les paquets UDP/1195 sont visibles à l’extérieur du VPN, donc sur l’interface ethernet (eth0 ?) et non l’interface tun/tap. Sur tun0, le plus simple est de tout capturer.

AMA “TCP segment of a reassembled PDU” affiché par wireshark correspond plutôt à la segmentation normale de TCP et pas à de la fragmentation IP. La taille réduite des segments (1407 octets) semble tenir compte de la surcharge d’encapsulation du VPN, pour éviter la fragmentation IP.

TCP dans TCP, ce n’est jamais terrible car la gestion de la congestion et des retransmissions des deux couches TCP empilées interfèrent l’une avec l’autre…

#14

Donc si je comprends bien, ce n’est pas fragmenté ?

#15

avec une trace tcpdump sur les interfaces tun et eth ce serait plus facile (pour moi) de vérifier.

#16

tcpdump -i eth0 udp port 1195 : op2.labz.fr/tcpdump.txt
tcpdump -v -i eth0 udp port 1195 : op2.labz.fr/tcpdump-v.txt
tcpdump -vv -i eth0 udp port 1195 : op2.labz.fr/tcpdump-vv.txt
tcpdump -vvv -i eth0 udp port 1195 : op2.labz.fr/tcpdump-vvv.txt

Environ 10Mo par fichier.

#17

Il n’était pas nécessaire de fournir une trace aussi volumineuse, un passage contenant quelques paquets de grosse taille (> 1000 octets) suffisait. Pas de fragmentation des paquets “à l’extérieur” du VPN en tout cas, ils ont même le flag “DF” qui empêche la fragmentation. Reste à vérifier à l’intérieur du VPN, avec

même si d’après la trace succinte de wireshark montrée plus haut cela ne semble pas être le cas non plus.

#18

En effet, ils ont aussi le flag “DF”… pastebin.com/2yC55SpS

#19

Là je ne sais plus trop quoi regarder.
Vous pensez qu’un VPN IPsec serait plus performant ?

#20

Traditionnel un VPN s’appuie sur IPSec (Internet Protocol Security) pour créer un tunnel entre les deux extrémités.
Je suis curieux de la réponse qui peut être donnée, mais je ne pense pas que cela fasse une différence…

Abonnement