IPsec通信が暗号エンジンによって高速化するのを体験してみた

2024年12月04日 水曜日


【この記事を書いた人】
梅津 勝平

SMF系サービスの開発・運用を担当しています。趣味は自宅サーバやアマチュア無線。systemdでできることはsystemdにやらせたい派です。

「IPsec通信が暗号エンジンによって高速化するのを体験してみた」のイメージ

IIJ 2024 TECHアドベントカレンダー 12/4の記事です】

2023年のアドベントカレンダーの記事としてIntel N100のミニPC上にSEIL/x86 Ayame (以下Ayame)を構築し、NGN網内折り返しのIPsecで東京の自宅と山形の実家間をつなぐ記事を執筆しました。その中でIPsecの速度測定を実施したところ、200~300Mbpsで頭打ちする結果となりました。

これについて部長(※1)より「(SEILと比べて)仮想環境のオーバーヘッドと暗号エンジンの有無により速度が出ていない(※2)」というコメントがありました。

※1:ちなみに、当部長はNetBSDの暗号エンジンのコントリビュータで、man に名前が掲載されたことがあります
※2:VMware環境であればQATによるHW支援が利用可能

アドベントカレンダー記事の構成は「自宅環境は可能な限りOSSで構築する」というポリシーからKVM上でAyameを動かしていたこともあり、純粋にCPUだけで処理をしている状態でした。

折よく、QAT(Intel QuickAssist Technology)という暗号エンジンが利用可能なCPU(Intel Atom C3538)を搭載した機材を入手できました。

そこで、QATを利用すればどの程度IPsecの速度が変化するか気になり、実際に測定しました。また、ほかの暗号エンジンではどうなのか気になったため、N100で利用可能なAES-NIを使用したケースと比較してみました。

 

構成

Rocky Linux 9.3をインストールした以下のホストにlibvirtをインストールしました。

これらの上にAyameやRockey9のVMを立て、iperf3による速度測定を行いました。条件をそろえるため、すべてのVMを2vCPUで統一しました。

LinuxでのIPsec接続にはLibreswanを使用しました。なお、QATは、SR-IOVによってゲストに渡して暗号エンジンを利用しました。

ホストではVFを16個生やし、そのうちの1つをゲストに渡しました。

LAN環境は1Gbps環境のため、この速度が測定上限となります。

 

ホストのスペック

識別子 CPU 暗号エンジン NIC
QAT母艦 Atom C3538 4C4T QAT 1G (SR-IOV対応)
N100母艦-0 N100 4C4T AES-NI 2.5G (SR-IOV非対応)
N100母艦-1 N100 4C4T AES-NI 2.5G (SR-IOV非対応)

 

ゲストの構成

識別子 用途 配置 OS 暗号エンジン vCPU RAM NICとVMの接続
Ayame終端 Ayame IPsec受信 N100母艦-0 SEIL/x86 Ayame なし 2 2GiB virtio
AES-NI終端 AESNI IPsec受信 N100母艦-0 Rocky Linux 9.3 AES-NI 2 6GiB virtio
QATR9 QAT IPsec送出 QAT母艦 Rocky Linux 9.3 QAT 2 6GiB SR-IOV
noQATR9 暗号エンジンなし IPsec送出 QAT母艦 Rocky Linux 9.3 なし 2 6GiB SR-IOV
Ayame始点 Ayame IPsec送出 QAT母艦 SEIL/x86 Ayame なし 2 2GiB SR-IOV
AES-NI始点 AESNI IPsec送出 N100母艦-1 Rocky Linux 9.3 AES-NI 2 6GiB virtio

 

試験環境

自宅に以下のような検証環境を用意しました。AES-NI同士の下回りの経路だけ異なるのは、途中で増やした測定項目のため継ぎ接ぎとなってしまいました。

IPsecのコンフィグ例

ikev2を使用しました。

また、実家と自宅をつなぐIPsecのための検証であるため、udp-encapsulationを強制して測定しました。これは、実家と自宅の間ではESPパケットが10Mbps程度からドロップする挙動を観測したためです。

libreswanのコンフィグ例

conn ipsec20
    vti-interface=ipsec20
    vti-routing=no
    leftvti=10.254.0.4/30
    mark=5/0xffffffff
    auto=start
    left=192.168.221.156
    right=192.168.100.1
    leftsubnet=0.0.0.0/0
    rightsubnet=0.0.0.0/0
    authby=secret
    ikev2=insist
    ike=aes256-sha256;modp2048
    esp=aes256-sha256
    encapsulation=yes
    ikelifetime=86400s
    salifetime=3600s

Ayameのコンフィグ例

interface.ipsec20.ipv4.source       : 192.168.100.1
interface.ipsec20.ipv4.destination  : 192.168.221.156
interface.ipsec20.preshared-key     : hogefugapiyo
interface.ipsec20.ipv4.address      : 10.254.0.1/30
interface.ipsec20.ipv4.remote       : 10.254.0.2
interface.ipsec20.ike.version       : 2
interface.ipsec20.nat-traversal     : force

Ayameから見たIPsecの状態

Ayame-libreswan、 Ayame-Ayameの間で同じ暗号モードで接続できていることが確認できました。

show status ikev2 (to libreswan)

[IKE SA]
  saconf                : interface.ipsec20
  local                 : 192.168.100.1:4500
  remote                : 192.168.221.156:4500
  initiator/responder   : responder
  initiator SPI         : 0x6cde2d7415bd8131
  responder SPI         : 0x3d3bef36d9fbe78f
  state                 : ESTABLISHED
  created               : Sat Apr 13 19:29:58 2024 (841s ago)
  last received         : Sat Apr 13 19:43:58 2024 (1s ago)
  encryption            : aes256
  prf                   : hmac-sha256
  integrity             : hmac-sha256
  dh-group              : modp2048
  my-identifier         : address 192.168.100.1
  peers-identifier      : address 192.168.221.156
  lifetime              : 27959s/28800s
  udp-encapsulation     : true
  keepalive             : enable
  [CHILD SA]
    SPI (in)            : 0xf66e375d
    SPI (out)           : 0x8176c38a
    created             : Sat Apr 13 19:29:58 2024 (841s ago)
    encryption          : aes256
    integrity           : hmac-sha256
    pfs-group           : (not rekeyed yet)
    lifetime of time    : 26159s/27000s
    [Traffic Selectors (source)]
      0.0.0.0-255.255.255.255 protocol:0(any) port:any
    [Traffic Selectors (destination)]
      0.0.0.0-255.255.255.255 protocol:0(any) port:any

show status ikev2 (to Ayame)

[IKE SA]
  saconf                : interface.ipsec22
  local                 : 192.168.100.1:4500
  remote                : 192.168.221.159:4500
  initiator/responder   : responder
  initiator SPI         : 0x5946fcc058da6965
  responder SPI         : 0x520c5fa0fe7c0ba0
  state                 : ESTABLISHED
  created               : Sat Apr 13 19:41:38 2024 (141s ago)
  last received         : Sat Apr 13 19:43:58 2024 (1s ago)
  encryption            : aes256
  prf                   : hmac-sha256
  integrity             : hmac-sha256
  dh-group              : modp2048
  my-identifier         : address 192.168.100.1
  peers-identifier      : address 192.168.221.159
  lifetime              : 28659s/28800s
  udp-encapsulation     : true
  keepalive             : enable
  [CHILD SA]
    SPI (in)            : 0xf518fbbd
    SPI (out)           : 0xa97697eb
    created             : Sat Apr 13 19:41:38 2024 (141s ago)
    encryption          : aes256
    integrity           : hmac-sha256
    pfs-group           : (not rekeyed yet)
    lifetime of time    : 26859s/27000s
    [Traffic Selectors (source)]
      0.0.0.0-255.255.255.255 protocol:0(any) port:any
    [Traffic Selectors (destination)]
      0.0.0.0-255.255.255.255 protocol:0(any) port:any

 

測定方法

測定にはiperf3を用いました。

事前検証にて、Iperf3の送信元インタフェースがbridgeやIPsecインタフェースといった仮想インタフェースの場合、ワイヤーレートの30%~50%程度でCPU使用率が100%になり頭打ちしました。このため、IPsecを張る機材の下流に配置した機材よりIperf3を実行し、IPsecだけに専念させました。

QAT母艦上に配置したVMを経由したIPsecの速度測定はN100母艦-1より実施しました。

N100母艦-1上に配置したAES-NI視点経由の速度測定には、この下流にノートPC(Ubuntu 22.04)を接続し測定を実施しました。

コマンドは以下のものを用いました。また、UDPの測定の場合、Loss率が5%程度となるような速度を指定して測定しました。

TCP

$ iperf3 -c 10.254.0.9 -t 20 -l 1220

UDP

$ iperf3 -c 10.254.0.9 -t 20 -l 1220 -u -b 180M

結果

本題の前に下回りの経路の通信速度を測定してからIPsecの通信速度を測定しました。

事前測定:下回りの速度測定

おおむね940Mbpsが下回りの実効値でした。

経路 TCP [Mbps]
N100母艦-1 QAT母艦->IX2215->N100母艦-0 940
T495 N100母艦-1 → N100母艦-0 938

 

Ayame終端への通信(受信暗号化なし)

この測定では、目立った差は見られませんでした。これは受け手であるAyame終端での処理が飽和したためです。

QATR9経由の通信で通信量を確認してみると、N100母艦-0ではVMのネットワークインターフェースに360Mbps(40MB/s)程度到達していることが確認できました。

このため、暗号エンジンなしでは違いが判らないため、終端をAES-NIを用いた構成にして測定しました。また、AES-NI同士で通信したケースを追加することにしました。

経由 暗号エンジン TCP [Mbps] UDP [Mbps]
QATR9 QAT 165 145
noQATR9 なし 222 241
Ayame-始点 なし 174 178

 

QATR9に向けて送出した通信(N100母艦-1にて観測)

 

Ayame終端へ到達した通信(N100母艦-0にて観測)

AES-NI終端 への通信 (受信AES-NI利用)

暗号エンジンの有無による速度差がはっきりとわかる結果となりました。しかし、暗号エンジンの違いは、下回りの速度が起因で頭打ちしたため見いだせませんでした。

(IPsecのMTUを1400程度と見積もった場合、5%程度のオーバーヘッドとすると900*1.05=945 となり下回りの速度とおおむね一致する)

しかし、実家とのIPsecに暗号エンジンを使った構成とすれば回線の性能をフルに発揮できることを確認できました。(NGNの折り返しで600Mbps程度速度が出ると確認できているため)

経由 暗号エンジン TCP [Mbps] UDP [Mbps]
QATR9 QAT 889 804
noQATR9 なし 339 301
Ayame始点 なし 187 193
AES-NI始点 AESNI 893 881

まとめ

暗号エンジンを使うことで暗号エンジンなしと比べて3~4倍程度高速に通信できることが確認できました。一方、暗号エンジンの違いは下回りの速度が原因で差が見えませんでした。これについては、将来10G化した際に再測定したいと考えています。

また、思いつくままに検証パターンを追加したため、構成が継ぎ接ぎとなってしまい通信の流れが分かりにくくなってしまいました。次に測定する場合はこのあたりを整理して測定したいです。

とはいえ、実家と自宅のIPsecに暗号エンジンを使えば回線の性能をフルに生かせるということが確認できました。

また、普段ネットワーク機器のコンフィグでしかIPsecを構成したことがなかったため、libreswanのコンフィグから設定したことはよい経験となりました。次は実際に暗号エンジンを使用した構成を検討したいと思います。(が、IPSecの設定を実家の機器に投入するにはIPsecが必要なブートストラップ問題が存在するため回避策を検討中です)

SEIL/x86 Ayame スタンダードエディション 割引コードプレゼント

本記事をご覧頂いた方へ、SEIL/x86 Ayame スタンダードエディションを50%OFFで購入できるプロモーションコードをプレゼント!
この機会にどうぞご利用ください。

プロモーションコード:AYAME24XMASP

※SEIL/x86 Ayameスタンダードエディション購入時に利用できるプロモーションコードです。(購入手続き画面で本コードを適用ください)
※本プロモーションコードで購入できるスタンダードエディションでは、1GbEの仮想イーサネットコントローラを使用できます。
※SEIL/x86 AyameスタンダードエディションはAmazonでご購入いただけます。

  • プロモーションコード有効期限:2024年12月25日(水)23:59
  • 本キャンペーンで購入した商品の転売行為は禁止いたします。

SEIL/x86 Ayame(ザイル・エックスハチロク アヤメ)とは?
仮想環境にインストールすることができる高機能ソフトウェアルータです。IPsec、L2TPv3 over IPsec、L2TP/IPsec等のVPN機能、OSPF、RIP、BGPなどの各種ダイナミックルーティング、ファイアウォール、IPv4ポリシールーティングなどの豊富な機能を利用できます。

SEIL/x86 Ayameについての詳細はこちら
https://www.seil.jp/product/x86ayame.html

IIJ Engineers blog読者プレゼントキャンペーン

Xのフォロー&条件付きツイートで、「IoT米」と「バリーくんシール」のセットを抽選でプレゼント!
応募期間は2024/12/02~2024/12/31まで。詳細はこちらをご覧ください。
今すぐポストするならこちら→ フォローもお忘れなく!

梅津 勝平

2024年12月04日 水曜日

SMF系サービスの開発・運用を担当しています。趣味は自宅サーバやアマチュア無線。systemdでできることはsystemdにやらせたい派です。

Related
関連記事