Kryptokort for en VPN-gateway: fire overleveringer før kjøp

Gamle kryptografiske akseleratorer dukker opp i PCI-inventaret, og antakelsen er at VPN-en nå krypterer raskere. Fire separate overleveringer må lykkes før det er sant: systemet finner enheten, en vedlikeholdt driver styrer den, et grensesnitt eksponerer operasjonen VPN-en trenger, og VPN-ens aktive backend ber om den. Hvis én svikter, blir kortet stående utenfor tunnelens reelle vei.

Oppdagelse er den første overleveringen, ikke den siste

Oppdagelse beviser bare at bussen ser en enhet og at kjernen har en viss idé om hva den er. Driverstøtte er neste port, og den er versjonsavhengig: en modul som fantes i en gammel utgivelse, kan mangle helt i den gjeldende kjernepakken. I tillegg må driveren registrere den spesifikke algoritmen og modusen som datakanalen bruker. Et kort som akselererer AES-CBC, gjør ingenting for en konfigurasjon som forhandler om AES-GCM.

Navngi hver overlevering separat i vurderingen, fordi en feil ved den fjerde ser identisk ut fra utsiden som en feil ved den første.

Les kjernens algoritmeinventar

Begynn med å samle inn det verten allerede vet om enheten og om algoritmene den har registrert.

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

PCI-linjen gir leverandør- og enhets-ID-ene som trengs for enhver driversøking, og/proc/crypto lister opp registrerte implementasjoner med driverne og prioritetene deres. En prioritetsverdi ordner valget mellom implementasjoner av samme algoritme, noe som ikke er det samme som at en applikasjon velger én av dem. Hvis kortets algoritme ikke vises der, har driveren aldri registrert den, og ingen endring i brukerrommet vil kalle på den. Noter ID-ene og implementasjonsnavnene i stedet for et skjermbilde av kortet.

VPN-en må velge nettopp den implementasjonen

Tilgjengelighet i kjernen er en meny, ikke en garanti for at VPN-prosessen har bestilt fra den. Sjekk hva backenden faktisk bruker.

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

Hastighetskommandoen øver på bibliotekets egen vei og gir en basislinje for maskinen slik den er konfigurert, mens motorlisten viser om det i det hele tatt finnes en valgfri leverandør tilgjengelig for OpenSSL. En VPN i brukerrommet med eget kryptobibliotek omgår kjerneimplementasjonene fullstendig, så en registrert driver kan være irrelevant for den. Avlastning av datakanalen er nok en tredje mekanisme, som endrer pakkebehandlingen i stedet for å sende chifferforespørsler til et utvidelseskort. Fastslå hvilken av de tre som beskriver utrullingen din før du kjøper maskinvare for den fjerde.

Sammenlign med CPU-veien du allerede har

Moderne prosessorer inneholder AES-instruksjoner som et vedlikeholdt bibliotek bruker uten ekstra maskinvare, og de unngår bussoverføringer og ekstra kopier. En gammel akselerator kan tape mot den veien mens den fortsatt rapporterer imponerende rå chifferetall. Mål den reelle arbeidsbelastningen: samme trafikk, samme beskyttelsesinnstillinger, basislinje mot kandidat, med CPU-belastning og applikasjonsgjennomstrømning registrert sammen. Ta med oppdaterings- og gjenopprettingsatferd i beslutningen, fordi en uveholdt modul øker vedlikeholdsrisikoen for gatewayen for hele levetiden.

Kjøpsgrunnlaget er en støttet kjede pluss en målt gevinst. Et oppdaget kort, eller en modul noen en gang kompilerte, er ingen grunn til å gjøre en vedlikeholdt gateway avhengig av utdatert maskinvare.