OpenVPN est lent

Support Debian
#4

Avant d’envisager de changer de chiffrement, il faut déterminer si c’est bien le CPU qui limite d’un côté ou de l’autre du VPN. Pour cela il suffit d’observer la charge CPU des deux noeuds à débit max dans chaque sens pendant assez longtemps.

Quand on empile toutes les couches, ça commence à faire :
IPv4 = 20 octets
UDP = 8 octets
OpenVPN = ?
IPv6 = 40 octets
TCP = 20 octets

L’encapsulation peut augmenter la taille des paquets au-delà de la MTU du chemin du tunnel, ce qui peut provoquer de la fragmentation. Deux cas :

  • si la MTU du tunnel n’est pas diminuée en conséquence, le tunnel fragmente après l’encapsulation (le paquet encapsulé n’est pas fragmenté, donc le paquet encapsulant est trop gros et doit être fragmenté)

  • si la MTU du tunnel est diminuée en conséquence, le tunnel fragmente avant l’encapsulation (le paquet encapsulé est trop gros et doit être fragmenté, chaque fragment est transporté dans un paquet encapsulant non fragmenté) ; quand tout se passe bien, TCP devrait s’adapter et limiter la taille des paquets pour éviter la fragmentation.

Dans les deux cas, la fragmentation résulte en l’envoi d’un fragment de taille maximum et d’un fragment de petite taille pour transmettre un paquet complet, ce qui fait chuter le débit effectif sans parler de la charge CPU pour gérer la fragmentation et le réassemblage à l’arrivée.

#5

Je pense que c’est ça, le processus openvpn prend 100 % du CPU sur Lookout (le client, un Raspberry Pi), c’est pour ça que je commence à penser que ça peut être ça.

Et tu ne comptes pas la couche liaison, mais bon, je ne sais pas s’il y en a une dans une interface en tun.

Ah, le MTU est très mal géré sur mon réseau, peut-être une petite optimisation à faire de ce côté. La connexion vers l’extérieur et la connexion VPN ont toutes les deux un MTU de 1500. Je m’amusais à gérer ça quand j’avais une connexion ADSL avec un MTU de 1492 et aucun VPN, mais là, je n’ai même pas réfléchi à la question.

#6

Probablement. Le processeur du Raspberry Pi n’est pas prévu pour faire du chiffrement intensif.

Normalement non. En mode tap c’est 14 octets d’en-tête ethernet.

C’est le cas n° 1, et ce n’est pas idéal : si on envoie un paquet de 1500 octets sur l’interface tun, le paquet encapsulant résultant aura une taille de plus de 1500 octets et devra être fragmenté. Comme les paquets encapsulants et encapsulés sont indépendants du point de vue du noyau, la couche IP n’a aucun moyen de signaler cette fragmentation à l’émetteur du paquet original afin qu’il réduise la taille de ses paquets (contrairement au cas n° 2). Seul le démon openvpn pourrait faire suivre les informations de fragmentation de la couche IP de transport à la couche IP transportée mais ce n’est pas trivial, j’ignore s’il le fait.

Tu pourrais progressivement réduire la MTU sur les interfaces tun des deux côtés pour voir si tu peux gagner un peu de débit. Mais si c’est le CPU qui limite à cause du chiffrement, le gain risque d’être modeste.

#7

une question bête quelle est la vitesse du port RJ du raspberry pi ?
il y a un autre probleme avec le rpi c’est que le bus est en usb 2

#8

Je ne vois pas de raison pour que la limitation du port ou du bus affecte différemment les flux dans le VPN et en dehors du VPN.

#9

Très bonne question, mais deux choses. D’abord, il s’agit du Raspberry Pi 4, ils sont passé à l’USB 3. Le port est donc en Gigabit. Ensuite :

#10

Je peux sans doute utiliser un chiffrement moins gourmand. Ne pas pouvoir dépasser les 30 Mbps avec un processeur quadruple-cœur à 1,5 GHz, c’est un peu rude.

#11

openvpn utilise à fond les 4 coeurs simultanément ?

#12

Non, justement, top indique 100 %, c’est que d’un seul cœur. Mais si on multiplie vite-fait par trois et demi, ça fait à peu plus de 100 Mbps, c’est toujours mieux, mais je ne sais pas du tout comment on fait utiliser toutes les ressources à openvpn.

#13

On ne peut pas. OpenVPN est connu pour ne fonctionner qu’en mono-processus.

A contrario, Wireguard utilise tous les threads d’une machine. Et le fait qu’il réside en grande partie dans le noyau permet de gagner encore plus en performances par rapport à OpenVPN.

Sur un appareil en x86 aux capacités limitées, je fais du gigabit symétrique avec Wireguard alors que je plafonnais à 300 Mbps avec OpenVPN.

Testé sur une Raspberry Pi 4 avec Ubuntu en 64 bits, là aussi Wireguard envoie du pâté !

–
AnonymousCoward

2 J'aime
#14

Wireguard ? Inconnu au bataillon, que ce soit sur le client ou le serveur. Bizarre, le site nous dit qu’il est dans les dépôts.

#15

Oui il est dans les backports de Buster ou dans les dépôts Bullseye et Sid, c’est plutôt récent.

#16

https://wiki.debian.org/WireGuard

les packages dans buster-backports

–
AnonymousCoward

#17

Heu, oui, ça résoult le problème pour le serveur, mais pas pour le client. Il n’y a pas de backports dans Raspbian.

#18

Il doit être disponible dans la branche unstable pour le côté serveur :wink:
Sinon tu le compile à la main et tu propose le backport :sweat_smile:

#19

Effectivement, il faut installer les paquets de Wireguard depuis les dépôts de Debian pour l’architecture armhf, si c’est pour Raspbian en 32 bits.

Il existe de nombreuses pages web décrivant l’installation de Wireguard sur Raspberry Pi.

Celle-ci me paraît bien : https://engineerworkshop.com/blog/how-to-set-up-wireguard-on-a-raspberry-pi/

Pour autant que je puisse le voir, la version de Wireguard est actuellement identique pour les suites unstable, testing et buster-backports : 1.0.20200513-1 .

D’après mon expérience pratique, utiliser une distribution en 64 bits pour la Raspberry Pi améliore pas mal les performances de la partie réseau en général.
Mais ce n’est normalement pas nécessaire, y compris sur un accès à Internet de type fibre optique pour un particulier.

–
AnonymousCoward

#20

Salut,
comme indiqué plus haut OpenVPN ne fonctionne que en mode monothread donc peu importe qu’il y ait un grand nombre de cœur, seul la puissance d’un seul sera utilisé.
Il est également important de savoir que le CPU du raspberry ne prends pas en charge le chiffrement matériel (pas d’instruction aes) ce qui implique une perte colossale de performance.

La piste de la MTU est également à vérifier, de manière générale, sur mes serveurs openVPN qui sont sur le réseau publique, je met la mtu à 1460 d’office. Dans ton cas je te suggère avec la commande Ping de voir la mtu entre tes deux serveurs connectés sans le vpn et ensuite de retirer 40 sur le résultat que tu auras eu afin d’avoir la MTU pour openVPN.

#21

Note pour les autres lecteurs : si c’est valable dans le cas présent (transport UDP/IPv4), c’est insuffisant dans le cas d’un transport UDP/IPv6 ou TCP/IPv4, sans parler de TCP/IPv6 car dans ces cas la taille de l’en-tête réseau+transport atteint ou dépasse 40 octets, auxquels il faut encore ajouter l’en-tête propre au protocole OpenVPN.

#22

Bonjour,

J’utilise énormément OpenVPN dans le cadre de mon boulot. Et très fréquemment lorsque j’ai des soucis de lenteur, c’est un soucis de MTU. Raison pour laquelle je mets le MTU a 1300 (oui c’est bas, mais ca marche ^^)
J’ai donc les options mssfix etfragment 1300(coté serveur et client bien sur)

Alors après j’ai vu que tu es en IPv6, et j’avoue que je n’ai encore mis aucun site en IPv6… je ne sais donc pas si les problématiques de MTU y sont les mêmes qu’en IPv4.

En espérant que ca aidera…

#23

Les problématiques de MTU sont globalement les mêmes en IPv6 à un détail près : seul l’émetteur d’un paquet peut le fragmenter, pas les routeurs intermédiaires (comme si l’indicateur DF « Don’t Fragment » de l’en-tête IP était systématiquement mis à 1). Si un paquet est trop gros pour être retransmis, il sera donc systématiquement jeté avec envoi d’un message d’erreur ICMPv6 de type « Packet too big » informant l’émetteur de la taille maximum admissible.

2 J'aime