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