Salut,

J'ai effectué des tests de performance sur la nouvelle machine (denis)
avec l'aide de pitchum.

Le résultat est plutôt pas mal à mon goût. En *gros* on a trois
catégories de ciphers du point de vue serveur :
- BF-CBC (ce qui est actuellement utilisé) : 7,5Mo/s max, CPU à 100% et,
  pour éviter l'attaque SWEET32, une renégotiation régulière (tous les
  64Mo de données échangées) qui plombe la performance pendant 1 à 2
  secondes ;
- AES-128-GCM et AES-256-GCM : 10Mo/s et CPU à 65% (je crois que c'est
  ma ligne de test qui limite le débit :) ) ;
- AES-128-CBC et AES-256-CBC : 10Mo/s et CPU à 85%.

Mon test était basique : un netcat sur le serveur, un sur le client, et
une communication avec les IP privées du lien VPN pour que je puisse
dire à openvpn de ne pas modifier mes routes.

Clairement le mieux c'est AES-{128,256}-GCM pour le serveur. J'ai aussi
été un peu surpris : normalement le 256 est pas mal plus cher (et pas
plus sûr, voire moins).
La différence entre les variantes GCM et CBC en très gros c'est qu'en
GCM, la vérification d'autenticité n'est pas dissociée de l'algo de
chiffrement alors qu'en CBC, c'est du SHA1 "à côté" et c'est
probablement ce qui fait que ça consomme davantage.

L'accélération matérielle divise le coût du chiffrement en aes-*-gcm par
10. J'ai aussi fait une petite mesure avec celle-ci désactivée et on
arrive à 100% de CPU pour un débit de 9,3Mo/s.
Avec un calcul à l'arrache, j'arrive à un coût de chiffrement de 4,7% de
CPU par MBps sans accélération, de 0,47% de CPU par MBps avec
accélération et 6% de CPU par MBps de paquets routés (MTU non regardée).

C'est à la fois bien et décevant : grâce à l'AES-NI, on consomme
nettement moins mais visiblement openvpn n'est pas efficace du tout et
désormais le routage d'openvpn représente 95% de la charge CPU.

Dans les points amusants, il y a ce qui s'est passé quand j'ai désactivé
le chiffrement : la charge CPU a augmenté pour atteindre celle observée
en AES-CBC.
Comme j'ai quitté le monde d'AES-GCM, openvpn a commencé à faire du SHA1
pour l'authentification des données et c'est purement en CPU
contrairement à l'AES-GCM : visiblement 2% de CPU par MBps (c'est
cohérent avec la vitesse relevée pour l'AES-CBC).

Je voulais aussi tester ChaCha20-Poly1305 de notre cher Daniel J.
Bernstein et al : ça devrait être nettement plus rapide sur les briques
(qui n'ont pas de capacités de chiffrement matériel). Malheureusement il
faudra probablement attendre openvpn 2.5 pour l'avoir. Sur les briques,
on continuera certainement de plus a être limité par le routage des
paquets par openvpn même si on peut espérer double le débit.

Tout ça me fait penser à wireguard. C'est pas du tout réalisé du côté
brique mais en termes de perf, on devrait ne plus être limités par le
routage des paquets (ou alors à un débit très nettement plus élevé). Ça
peut être un truc fun à monter en plus.

J'ai aussi commencé à tester cette histoire de choix dynamique de
cipher : avec un openvpn 2.4 on peut faire en sorte qu'un openvpn 2.3
soit en BF-CBC et que les autres soient en AES-128-GCM par exemple. La
doc d'openvpn pour 'ncp-ciphers' indique ce qu'il faut utiliser et ça
fonctionne bien.

Ce qu'il me manque encore c'est justement un test côté avec une brique.
La config en openvpn 2.4 est simple : avec la négociation côté serveur,
il n'y a que la config côté client pour choisir le cipher. Il faut que
je nettoie un peu la config mais sinon il faut juste 10 minutes pour
tester.

Pour finir, j'ai regardé de manière superficielle la latence de ce VPN :
elle semble bien meilleure. Il faudrait comparer entre Auxerre et
Saint-Denis (et à Saint-Denis on peut faire de l'IPv6).

-- 
Adrien