Cryptokaart voor een VPN-gateway: vier overdrachten vóór de aankoop

Oude cryptografische versnellers duiken op in de PCI-inventaris, en men gaat ervan uit dat de VPN nu sneller versleutelt. Vier afzonderlijke overdrachten moeten slagen voordat dat waar is: het systeem vindt het apparaat, een onderhouden driver bestuurt het, een interface stelt de bewerking beschikbaar die de VPN nodig heeft, en de actieve backend van de VPN vraagt erom. Als er één faalt, blijft de kaart buiten het werkelijke pad van de tunnel.

Detectie is de eerste overdracht, niet de laatste

Detectie bewijst alleen dat de bus een apparaat ziet en dat de kernel enig idee heeft wat het is. Driverondersteuning is de volgende poort, en die is versieafhankelijk: een module uit een oude release kan volledig ontbreken in het huidige kernelpakket. Bovendien moet de driver het specifieke algoritme en de modus registreren die het datakanaal gebruikt. Een kaart die AES-CBC versnelt, doet niets voor een configuratie die over AES-GCM onderhandelt.

Benoem elke overdracht afzonderlijk in de evaluatie, want een fout bij de vierde ziet er van buiten identiek uit aan een fout bij de eerste.

Lees de algoritme-inventaris van de kernel

Begin met het verzamelen van wat de host al weet over het apparaat en over de algoritmen die het heeft geregistreerd.

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

De PCI-regel geeft de leverancier- en apparaat-ID's die nodig zijn voor elke driverzoektocht, en/proc/crypto somt de geregistreerde implementaties op met hun drivers en prioriteiten. Een prioriteitswaarde ordent de keuze tussen implementaties van hetzelfde algoritme, wat niet hetzelfde is als dat een toepassing er een kiest. Als het algoritme van de kaart daar niet verschijnt, heeft de driver het nooit geregistreerd en geen enkele wijziging in de gebruikersruimte zal het aanroepen. Noteer de ID's en implementatienamen in plaats van een schermafbeelding van de kaart.

De VPN moet die implementatie selecteren

Beschikbaarheid in de kernel is een menu, geen garantie dat het VPN-proces daaruit heeft besteld. Controleer wat de backend werkelijk gebruikt.

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

De snelheidsopdracht oefent het eigen pad van de bibliotheek en geeft een basislijn voor de machine zoals geconfigureerd, terwijl de engine-lijst toont of er überhaupt een optionele provider beschikbaar is voor OpenSSL. Een VPN in de gebruikersruimte met een eigen cryptobibliotheek omzeilt kernelimplementaties volledig, dus een geregistreerde driver kan er irrelevant voor zijn. Het offloaden van het datakanaal is weer een derde mechanisme, dat de pakketverwerking verandert in plaats van cijferverzoeken naar een uitbreidingskaart te sturen. Stel vast welke van die drie uw implementatie beschrijft voordat u hardware voor de vierde koopt.

Vergelijk met het CPU-pad dat u al hebt

Moderne processors bevatten AES-instructies die een onderhouden bibliotheek zonder extra hardware gebruikt, en ze vermijden busoverdrachten en extra kopieën. Een oude versneller kan tegen dat pad verliezen terwijl hij nog steeds indrukwekkende ruwe cijfergetallen rapporteert. Meet de werkelijke belasting: hetzelfde verkeer, dezelfde beveiligingsinstellingen, basislijn tegen kandidaat, met CPU-belasting en applicatiedoorvoer samen vastgelegd. Neem het gedrag bij updates en herstel mee in de beslissing, want een niet-onderhouden module verhoogt het onderhoudsrisico van de gateway voor zijn hele levensduur.

De aankoopgrond is een ondersteunde keten plus een gemeten voordeel. Een gedetecteerde kaart, of een module die iemand ooit compileerde, is geen reden om een onderhouden gateway afhankelijk te maken van verouderde hardware.