Carte cryptographique pour une passerelle VPN : quatre transmissions avant l'achat

Les anciens accélérateurs cryptographiques apparaissent dans l'inventaire PCI, et l'on suppose que le VPN chiffrera désormais plus vite. Quatre transmissions distinctes doivent réussir avant que cela soit vrai : le système trouve le périphérique, un pilote maintenu le pilote, une interface expose l'opération dont le VPN a besoin, et le backend actif du VPN la demande. Si une seule échoue, la carte reste en dehors du chemin réel du tunnel.

La détection est la première transmission, pas la dernière

La détection prouve seulement que le bus voit un périphérique et que le noyau a une certaine idée de ce qu'il est. La prise en charge par le pilote est la porte suivante, et elle dépend de la version : un module présent dans une ancienne version peut manquer entièrement dans le paquet actuel du noyau. En outre, le pilote doit enregistrer l'algorithme et le mode précis qu'utilise le canal de données. Une carte qui accélère AES-CBC ne fait rien pour une configuration qui négocie AES-GCM.

Nommez chaque transmission séparément dans l'évaluation, car une défaillance à la quatrième paraît identique de l'extérieur à une défaillance à la première.

Lisez l'inventaire d'algorithmes du noyau

Commencez par rassembler ce que l'hôte sait déjà du périphérique et des algorithmes qu'il a enregistrés.

lspci -nn | grep -i -E "crypt|hifn|soekris"
grep -E "^(name|driver|priority)" /proc/crypto | head -40

La ligne PCI fournit les identifiants de fabricant et de périphérique nécessaires à toute recherche de pilote, et/proc/crypto liste les implémentations enregistrées avec leurs pilotes et leurs priorités. La valeur de priorité ordonne la sélection entre les implémentations d'un même algorithme, ce qui n'est pas la même chose qu'une application qui en choisit une. Si l'algorithme de la carte n'y figure pas, le pilote ne l'a jamais enregistré et aucune modification de l'espace utilisateur ne l'appellera. Notez les identifiants et les noms d'implémentation plutôt qu'une capture d'écran de la carte.

Le VPN doit sélectionner cette implémentation

La disponibilité dans le noyau est un menu, pas une garantie que le processus VPN y ait passé commande. Vérifiez ce que le backend utilise réellement.

openssl speed -evp aes-256-gcm
openssl engine -t -c

La commande de débit exerce le chemin propre de la bibliothèque et donne une référence pour la machine telle qu'elle est configurée, tandis que la liste des moteurs indique si un fournisseur optionnel est disponible pour OpenSSL. Un VPN en espace utilisateur doté de sa propre bibliothèque cryptographique contourne entièrement les implémentations du noyau, si bien qu'un pilote enregistré peut lui être indifférent. Le déport du canal de données est encore un troisième mécanisme, qui modifie le traitement des paquets au lieu d'envoyer des requêtes de chiffrement à une carte d'extension. Déterminez lequel de ces trois décrit votre déploiement avant d'acheter du matériel pour le quatrième.

Comparez avec le chemin CPU dont vous disposez déjà

Les processeurs modernes incluent des instructions AES qu'une bibliothèque maintenue utilise sans matériel supplémentaire, et ils évitent les transferts de bus et les copies superflues. Un ancien accélérateur peut perdre face à ce chemin tout en affichant des chiffres bruts de chiffrement impressionnants. Mesurez la charge réelle : même trafic, mêmes réglages de protection, référence contre candidat, avec la charge du processeur et le débit applicatif enregistrés ensemble. Intégrez le comportement de mise à jour et de reprise à la décision, car un module non maintenu augmente le risque de maintenance de la passerelle pendant toute sa durée de vie.

Le motif d'achat est une chaîne prise en charge plus un bénéfice mesuré. Une carte détectée, ou un module que quelqu'un a compilé autrefois, ne justifie pas de rendre une passerelle maintenue dépendante de matériel obsolète.