VPN 게이트웨이용 암호 카드: 구매 전 네 번의 인계

오래된 암호 가속기는 PCI 목록에 나타나고, 이제 VPN이 더 빠르게 암호화할 것이라고 가정하게 된다. 그것이 사실이 되려면 네 번의 별개 인계가 성공해야 한다. 시스템이 장치를 찾고, 유지 관리되는 드라이버가 그것을 구동하며, 인터페이스가 VPN이 필요로 하는 연산을 노출하고, VPN의 활성 백엔드가 그것을 요청한다. 어느 하나라도 실패하면 카드는 터널의 실제 경로 밖에 남는다.

감지는 첫 번째 인계이지 마지막이 아니다

감지는 버스가 장치를 본다는 것과 커널이 그것이 무엇인지 어렴풋이 안다는 것만 증명한다. 드라이버 지원이 다음 관문이며 버전에 따라 다르다. 옛 릴리스에 있던 모듈이 현재 커널 패키지에서는 완전히 빠져 있을 수 있다. 게다가 드라이버는 데이터 채널이 사용하는 특정 알고리즘과 모드를 등록해야 한다. AES-CBC를 가속하는 카드는 AES-GCM을 협상하는 구성에 아무것도 해 주지 않는다.

평가에서는 각 인계를 따로 이름 붙여라. 네 번째에서의 실패는 밖에서 보면 첫 번째에서의 실패와 똑같이 보이기 때문이다.

커널의 알고리즘 목록을 읽어라

호스트가 장치와 등록한 알고리즘에 대해 이미 알고 있는 것을 모으는 것으로 시작하라.

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

PCI 줄은 드라이버를 찾는 데 필요한 공급업체 및 장치 식별자를 주고,/proc/crypto 등록된 구현을 그 드라이버와 우선순위와 함께 나열한다. 우선순위 값은 같은 알고리즘의 구현 사이에서 선택을 정렬하는 것이며, 애플리케이션이 그중 하나를 고르는 것과는 같지 않다. 카드의 알고리즘이 거기에 나타나지 않으면 드라이버가 그것을 등록한 적이 없고 사용자 공간의 어떤 변경도 그것을 호출하지 않는다. 카드의 화면 캡처 대신 식별자와 구현 이름을 기록하라.

VPN이 그 구현을 선택해야 한다

커널에서의 가용성은 메뉴이며, VPN 프로세스가 거기서 주문했다는 보장이 아니다. 백엔드가 실제로 무엇을 쓰는지 확인하라.

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

속도 명령은 라이브러리 자체의 경로를 시험하고 구성된 대로의 기계에 기준선을 준다. 반면 엔진 목록은 OpenSSL에 선택적 공급자가 아예 있는지 보여 준다. 자체 암호 라이브러리를 쓰는 사용자 공간 VPN은 커널 구현을 완전히 우회하므로 등록된 드라이버가 그것에 무관할 수 있다. 데이터 채널 오프로드는 또 다른 세 번째 방식으로, 암호 요청을 확장 카드로 보내는 대신 패킷 처리를 바꾼다. 네 번째를 위해 하드웨어를 사기 전에 이 셋 중 무엇이 당신의 배포를 설명하는지 확정하라.

이미 가진 CPU 경로와 비교하라

현대 프로세서에는 AES 명령이 들어 있고 유지 관리되는 라이브러리는 추가 하드웨어 없이 그것을 쓰며, 버스 전송과 여분의 복사를 피한다. 오래된 가속기는 인상적인 원시 암호 수치를 보고하면서도 그 경로에 질 수 있다. 실제 작업 부하를 측정하라. 같은 트래픽, 같은 보호 설정, 기준선 대 후보로, CPU 부하와 애플리케이션 처리량을 함께 기록한다. 갱신과 복구 동작도 결정에 포함하라. 유지 관리되지 않는 모듈은 게이트웨이의 수명 전체에 걸쳐 유지 보수 위험을 높이기 때문이다.

구매 근거는 지원되는 사슬과 측정된 이익이다. 감지된 카드나 누군가 한때 컴파일한 모듈은 유지 관리되는 게이트웨이를 구식 하드웨어에 의존하게 만들 이유가 아니다.