ぷららのTransix DS-Lite（IPv4 over IPv6）からのアクセスがヨーロッパ圏からのアクセス？
transix DS-Liteは、日本国内にあるかと。。。
IPアドレスで判断する愚。。。。
また、ぷららのサポートに問い合わせるのかな。。。。。
transix DS-Liteは、日本国内にあるかと。。。
IPアドレスで判断する愚。。。。
また、ぷららのサポートに問い合わせるのかな。。。。。
「Windows L2TP/IPSec VPN接続」で検索すると「AssumeUDPEncapsulationContextOnSendRule」を設定する情報に出会う。ヤマハのNVR500にL2TP/IPSec機能が追加され（2017年10月）設定を行った。Windows10でL2TP/IPSec接続時にNVR500に記録される「ISAKMP複合鍵」確認時に「AssumeUDPEncapsulationContextOnSendRule」を設定しなくても接続できる事を確認していた。
Windows OSとNVR500のL2TP/IPSec VPN接続スループットを確認していた時に「NAT」を使用していないのに「AssumeUDPEncapsulationContextOnSendRule」設定で接続可能となったので記録しておく。
「NVR500 L2TP/IPsecの最大VPN回線速度計測」と同様の構成で「172.24.0.0/16のGBT回線」に接続したWindows OS機からNVR500のL2TP/IPSec VPNに接続してスループット計測を試みた。「Windows10（Ver. 1809/OS build 17763.737）on Parallels Desktop 14 for Mac（ver. 14.1.3(45485)） on macOS Mojave（10.14.6）」構成でCore i7 - 4850HQの「4Core/16Gメモリ」から「2Core/2Gメモリ」をWindowsに割当てある。
Windows10にIPv4アドレス「172.24.1.80/16」を設定し、L2TP/IPsec接続したところエラーで接続出来なくなった。
原因を探るため「Dynabook SS RX2/T7H（Core 2 Duo - U9300@1.2Ghz/3Gメモリ）Windows7 32bit（ver. 6.1.7601）」で調査した。
「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x0」を確認
「172.24.1.90/16」を静的に設定し、Default Gateway「172.24.1.2」でNVR500から「DS-Lite」経由でインターネットアクセスが出来るよう設定
ぷららIPv4 over PPPoEで公開しているL2TP/IPsec VPNサーバ「AAAAAAAA.BBN.netvolante.jp」にL2TP/IPsecでVPN接続させる。問題なく接続できる。このVPN接続名を「L2TP-IPsec-Internet」としている。
VPN接続端末には、「192.168.11.16」がアサインされる。
Windows10でも同じ。
VPNサーバアドレスを「172.24.1.2」としたVPN接続名「L2TP-IPsec-local」を設定して接続する。
Windows10と同様にエラーで接続出来ない。
「L2TP-IPsec-Internet」では、NVR500からIPv4 over IPv6でtransix「DS-Lite」へtunnel転送され、AFTRで「NAPT」変換され、ぷららのIPv4 over PPPoEで公開しているNVR500のL2TP/IPSec VPNサーバに接続する。NVR500では、ぷららのグローバルIPv4アドレスから「NAPT」でイントラネット内のプライベートIPv4アドレスに変換され接続する。NAT-Traversal（ポート4500）が使われている。
「L2TP-IPsec-local」では、NVR500のL2TP/IPSec VPNサーバに直接ローカルアドレスで接続し「NAPT」を介さない。全てのポート及びプロトコルが利用できるようフィルタも設定していない。
万策尽きて「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x2」を設定してみた
「L2TP-IPsec-local」もVPN接続できるようになった。。。
VPN接続端末には、「192.168.11.16」がアサインされる
debian10サーバを「192.168.11.0/24」にDHCP接続（192.168.11.16を取得）し「iperf3 -s」で起動。L2TP/IPsecが取得していた「192.168.11.16」が取られてしまった。NVR500のL2TP/IPsec接続端末へのIP設定は、DHCPプールから設定されるよう設計しているのだが、一度使われたIPが直ぐに再利用されて「192.168.11.17」が設定された。不思議。。。
接続後、ipref3サーバを使いスループット測定。
「Windows10 on Parallels Desktop on macOS Mojave」でも同様に「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x2」でローカル接続が出来るようになった。
「NVR500側の問題」なのか「Windows側」の問題なのか不明。パケットキャプチャすれば少し判るかも。。。
「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x0」の時、NVR500側で受信側SAが複数生成されるので、Windows側から複数回のリトライが行われている。NVR500のdebug logでは、経路中にNATの存在を検出している（構成図の通り経路中にNATは存在しない）。
-------- NVR500 system.log(debug on) --------
2019/09/14 23:03:10: [IKE] respond ISAKMP phase to 172.24.1.90
2019/09/14 23:03:10: [IKE] add ISAKMP context [2516] dd4d9aec1830541e 00000000
2019/09/14 23:03:10: [IKE] invalid ISAKMP proposal
2019/09/14 23:03:10: [IKE] ISAKMP SA attribute (group description) 20
2019/09/14 23:03:10: [IKE] invalid ISAKMP proposal
2019/09/14 23:03:10: [IKE] ISAKMP SA attribute (group description) 19
2019/09/14 23:03:11: [IKE] NAT Traversal: NAT box detected, start keepalive timer
2019/09/14 23:03:11: [IKE] calculate Diffie-Hellman value
--------
回避策
経路中にNATが無くてもWIndows OS側で
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule = (DWORD)0x2
とする
------ 2019/10/30 追記
NVR500が原因かWindowsが原因かWiresharkを使ってパケット解析し原因を探ってみた。
「Windows L2TP/IPSec VPN接続時のAssumeUDPEncapsulationContextOnSendRuleについて#2」
Windows OSとNVR500のL2TP/IPSec VPN接続スループットを確認していた時に「NAT」を使用していないのに「AssumeUDPEncapsulationContextOnSendRule」設定で接続可能となったので記録しておく。
「NVR500 L2TP/IPsecの最大VPN回線速度計測」と同様の構成で「172.24.0.0/16のGBT回線」に接続したWindows OS機からNVR500のL2TP/IPSec VPNに接続してスループット計測を試みた。「Windows10（Ver. 1809/OS build 17763.737）on Parallels Desktop 14 for Mac（ver. 14.1.3(45485)） on macOS Mojave（10.14.6）」構成でCore i7 - 4850HQの「4Core/16Gメモリ」から「2Core/2Gメモリ」をWindowsに割当てある。
Windows10にIPv4アドレス「172.24.1.80/16」を設定し、L2TP/IPsec接続したところエラーで接続出来なくなった。
原因を探るため「Dynabook SS RX2/T7H（Core 2 Duo - U9300@1.2Ghz/3Gメモリ）Windows7 32bit（ver. 6.1.7601）」で調査した。
「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x0」を確認
「172.24.1.90/16」を静的に設定し、Default Gateway「172.24.1.2」でNVR500から「DS-Lite」経由でインターネットアクセスが出来るよう設定
ぷららIPv4 over PPPoEで公開しているL2TP/IPsec VPNサーバ「AAAAAAAA.BBN.netvolante.jp」にL2TP/IPsecでVPN接続させる。問題なく接続できる。このVPN接続名を「L2TP-IPsec-Internet」としている。
VPN接続端末には、「192.168.11.16」がアサインされる。
Windows10でも同じ。
VPNサーバアドレスを「172.24.1.2」としたVPN接続名「L2TP-IPsec-local」を設定して接続する。
Windows10と同様にエラーで接続出来ない。
「L2TP-IPsec-Internet」では、NVR500からIPv4 over IPv6でtransix「DS-Lite」へtunnel転送され、AFTRで「NAPT」変換され、ぷららのIPv4 over PPPoEで公開しているNVR500のL2TP/IPSec VPNサーバに接続する。NVR500では、ぷららのグローバルIPv4アドレスから「NAPT」でイントラネット内のプライベートIPv4アドレスに変換され接続する。NAT-Traversal（ポート4500）が使われている。
「L2TP-IPsec-local」では、NVR500のL2TP/IPSec VPNサーバに直接ローカルアドレスで接続し「NAPT」を介さない。全てのポート及びプロトコルが利用できるようフィルタも設定していない。
万策尽きて「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x2」を設定してみた
「L2TP-IPsec-local」もVPN接続できるようになった。。。
VPN接続端末には、「192.168.11.16」がアサインされる
debian10サーバを「192.168.11.0/24」にDHCP接続（192.168.11.16を取得）し「iperf3 -s」で起動。L2TP/IPsecが取得していた「192.168.11.16」が取られてしまった。NVR500のL2TP/IPsec接続端末へのIP設定は、DHCPプールから設定されるよう設計しているのだが、一度使われたIPが直ぐに再利用されて「192.168.11.17」が設定された。不思議。。。
接続後、ipref3サーバを使いスループット測定。
「Windows10 on Parallels Desktop on macOS Mojave」でも同様に「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x2」でローカル接続が出来るようになった。
「NVR500側の問題」なのか「Windows側」の問題なのか不明。パケットキャプチャすれば少し判るかも。。。
「AssumeUDPEncapsulationContextOnSendRule=(dword) 0x0」の時、NVR500側で受信側SAが複数生成されるので、Windows側から複数回のリトライが行われている。NVR500のdebug logでは、経路中にNATの存在を検出している（構成図の通り経路中にNATは存在しない）。
-------- NVR500 system.log(debug on) --------
2019/09/14 23:03:10: [IKE] respond ISAKMP phase to 172.24.1.90
2019/09/14 23:03:10: [IKE] add ISAKMP context [2516] dd4d9aec1830541e 00000000
2019/09/14 23:03:10: [IKE] invalid ISAKMP proposal
2019/09/14 23:03:10: [IKE] ISAKMP SA attribute (group description) 20
2019/09/14 23:03:10: [IKE] invalid ISAKMP proposal
2019/09/14 23:03:10: [IKE] ISAKMP SA attribute (group description) 19
2019/09/14 23:03:11: [IKE] NAT Traversal: NAT box detected, start keepalive timer
2019/09/14 23:03:11: [IKE] calculate Diffie-Hellman value
--------
回避策
経路中にNATが無くてもWIndows OS側で
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule = (DWORD)0x2
とする
------ 2019/10/30 追記
NVR500が原因かWindowsが原因かWiresharkを使ってパケット解析し原因を探ってみた。
「Windows L2TP/IPSec VPN接続時のAssumeUDPEncapsulationContextOnSendRuleについて#2」
Intel Core i7の性能を調べている時に「AES-NI（AES-New Instructions）」と言うAES暗号化処理を支援する命令セットが使用出来る事を知った（2011年発売のCore i7-2600にも装備されいた。。。）。「Using Intel® AES New Instructions and PCLMULQDQ to Significantly Improve IPSec Performance on Linux」によると「AES-GCM」で400%高速化が実現したと。
strongSwan 5.3.1（2015年6月）から「aesni plugin（provides CBC, CTR, XCBC, CMAC, CCM and GCM crypto primitives for AES-128/192/256）」が提供されていた。
「macOS MojaveのIKEv2 IPsec VPN最大回線速度計測」で「aes256-cbc」のスループット688Mbps、「128aes-cbc」のスループット827Mbpsが計測された。
プラグインを確認すると「aesni」プラグインがロードされている。プラグインがロードされないように設定しても計測値が変わらない。IPSecのESPパケット暗号化は、カーネルで行われていてプラグインのロードと無関係に命令セットが使われているようだ。
「Macbook pro（macOS Mojave）」のIKEv2 VPNから「aes128-cbc」「aes256-cbc（default）」「aes128-gcm」「aes256-gcm」でスループットを計測確認してみた。
（１）macOS VPNアプリの設定
macOSのIKEv2 VPNアプリは、暗号化方式を選択できない。暗号化方式を指定して接続するには、構成プロファイル VPNペイロードで指定する必要がある。実際のプロファイルは、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」で利用したプロファイルを基にした。「IKE」は、変更せずに「ESP」の暗号化方式と認証方式だけを変更した。変更した構成プロファイルは、iOSにも利用できる。
--- 2019/9/10追記：GCM指定時に設定していた「Integirity」を未指定に変更。
（２）strongSwanの設定
GCMが選択できるように「esp=」にGCMを追加
---2019/9/10追記：GCM指定を変更
（３）計測
opensslで「Core i7-2600」の「AES-NI」が有効か確認処理速度をopensslで確認約5.9倍の処理速度で「AES-NI」が有効であることが確認できる。
AES128CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES128GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
結果
Core i5-8400の例だと「AES128CBC:1.28Gbps」「AES128GCM128: 2.59Gbps」のスループットが得られているようだが、「AES128-CBCとAES128GCM16」で、これほどの差は得られていない。ほぼ同等スループットなので、暗号化方式以外の処理が支配的で、Core i7-2600のCPU処理能力の結果であろうか。。。
--- 2019/9/10追記：GCM指定時に「Integrity」指定を削除したが、スループットに変化なし
strongSwan 5.3.1（2015年6月）から「aesni plugin（provides CBC, CTR, XCBC, CMAC, CCM and GCM crypto primitives for AES-128/192/256）」が提供されていた。
「macOS MojaveのIKEv2 IPsec VPN最大回線速度計測」で「aes256-cbc」のスループット688Mbps、「128aes-cbc」のスループット827Mbpsが計測された。
プラグインを確認すると「aesni」プラグインがロードされている。プラグインがロードされないように設定しても計測値が変わらない。IPSecのESPパケット暗号化は、カーネルで行われていてプラグインのロードと無関係に命令セットが使われているようだ。
「Macbook pro（macOS Mojave）」のIKEv2 VPNから「aes128-cbc」「aes256-cbc（default）」「aes128-gcm」「aes256-gcm」でスループットを計測確認してみた。
（１）macOS VPNアプリの設定
macOSのIKEv2 VPNアプリは、暗号化方式を選択できない。暗号化方式を指定して接続するには、構成プロファイル VPNペイロードで指定する必要がある。実際のプロファイルは、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」で利用したプロファイルを基にした。「IKE」は、変更せずに「ESP」の暗号化方式と認証方式だけを変更した。
AES-128-CBC
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-128</string>
<key>IntegrityAlgorithm</key>
<string>SHA1-96</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
AES-256-CBC
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-256</string>
<key>IntegrityAlgorithm</key>
<string>SHA2-256</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
AES-128-GCM
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-128-GCM</string>
<key>IntegrityAlgorithm</key>
<string>SHA1-96</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
AES-256-GCM
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-256-GCM</string>
<key>IntegrityAlgorithm</key>
<string>SHA2-256</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
--- 2019/9/10追記：GCM指定時に設定していた「Integirity」を未指定に変更。
（２）strongSwanの設定
GCMが選択できるように「esp=」にGCMを追加
/etc/ipsec.conf
conn %default
keyexchange=ikev2
#for Windows10 IKEv2 VPN
ike=aes256-sha256-modp1024
#for GCM testing
esp=aes128gcm16-sha, aes256gcm16-sha256
auto=add
left=%any
leftauth=pubkey
leftsubnet=192.168.0.0/20,2409:10:XXXX:YY00::/56,2404:1a8::/32
#for iOS VPN apli
leftsendcert=always
leftcert=debian10-pub.pem
leftid=@vpn.AAAAAAAA.mydns.jp
right=%any
rightsourceip=192.168.15.0/24,2409:10:XXXX:YY30::15:0/120
rightdns=192.168.11.250,2409:10:XXXX:YY20::11:250（３）計測
opensslで「Core i7-2600」の「AES-NI」が有効か確認
root@debian10:~$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 42
Model name: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Stepping: 7
CPU MHz: 1596.243
CPU max MHz: 3800.0000
CPU min MHz: 1600.0000
BogoMIPS: 6784.69
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts
openssl speed aes-256-cbc
OpenSSL 1.1.1c 28 May 2019
built on: Thu May 30 15:27:48 2019 UTC
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256 cbc 84293.98k 89436.65k 90589.10k 91029.16k 91187.88k 91247.96k
openssl speed -evp aes-256-cbc
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-cbc 393369.35k 491012.78k 523522.90k 532274.52k 534899.37k 535183.36k
AES128CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES128GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
結果
AES128-CBC 825Mbps AES256-CBC 682Mbps AES128GCM16 878Mbps AES256GCM16 824Mbps
Core i5-8400の例だと「AES128CBC:1.28Gbps」「AES128GCM128: 2.59Gbps」のスループットが得られているようだが、「AES128-CBCとAES128GCM16」で、これほどの差は得られていない。ほぼ同等スループットなので、暗号化方式以外の処理が支配的で、Core i7-2600のCPU処理能力の結果であろうか。。。
--- 2019/9/10追記：GCM指定時に「Integrity」指定を削除したが、スループットに変化なし
「NVR500 L2TP/IPsec VPN最大回線速度計測」で使用したMacbook proの能力を確認してみた。
Macbook pro（Late 2013 ）仕様
macOS Mojave 10.14.6
Core i7 - 4850HQ （2.3Ghz [3.5]）第4世代
IKEv2 IPsec サーバー（Dell XPS8300）
Debian 10 （Buster）
strongSwan 5.7.2
Core i7 - 2600（3.4Ghz [3.8]） 第2世代
確認したネットワーク構成は下記の通り
「NVR500 L2TP/IPsec VPN最大回線速度計測」と同様に、「192.168.1.0/24」のネットワークに「Debian10」を設置。Debian10は、「firmware-10.0.0-amd64-DVD-1.iso」で基本パッケージ+SSH+WEB + iperf3 + strongswan + libcharon-extra-plugins + resolvconf + dnsutils + net-toolsのルータ構成。ひかり電話HGWからDHCPでIPv4アドレス「192.168.1.57」を設定し、IPv6アドレスはstaticで「2409:10:XXXX:YY00::1:110」を設定した。このIPv6アドレスをドメイン名「vpn.AAAAAAAA.mydns.jp」でDDNSに登録。Debian10の二つ目のEthernetインターフェースにIPv4「192.168.14.1/24」、DHCPv6-PDで得たPrefix「2409:10:XXXX:YY30::/60」からIPv6「2409:10:XXXX:YY30::14:1/64」をそれぞれstatic設定した。
Debian10には、スループット計測用iperf3をサーバ起動させ計測した（手持ちPC不足のため）。
strongSWAN接続端末側の「riightsourceip」は、「192.168.15.0/24」「2409:10:XXXX:YY30::15:0/120」から設定されるよう設計した。
strongSwan設定は、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」と同様とした。
接続確認
macOS Mojave標準選択ESP暗号化方式
ESP暗号化方式指定「ike=aes128-sha!」
iperf3をIKEv2/IPsecサーバで動作させることによる影響確認
IKEv2/IPsecサーバ上でiperf3を二つ起動させる
iperf3 -s -D -B 192.168.1.57 --logfile iperf3-log-1-57.txt
iperf3 -s -D -B 192.168.14.1 --logfile iperf3-log-14-1.txt
コンソールから「iperf3 -c 192.168.14.1 -t 120」で同一サーバ上でのスループット計測をした場合としない場合でIKEv2/IPsec VPN接続と接続端末から「iperf3 -c 192.168.1.57 -t 60」でスループット計測を行い影響度を確認した。
IPv4 over IKEv2/IPsec over IPv6のMTUを確認
NGN経由のIPv6 IPoEのMTUは、1500。IKEv2/IPsecのMTUは、1406であるが、macOS MojaveのipsecインターフェースのMTUは、1400。
一応確認
接続端末（Macbook pro）からサーバ側へ「ping -s 1372 -c 3 192.168.14.1」（pingデータ長+IPv4(20)+TCP(8)=1400）まで応答がある事を確認
サーバ側からVPN端末へ「ping -s 1372 -c3 192.168.15.1」まで応答がある事を確認
IPv4 over IKEv2/IPsec over IPv6のスループットを計測
iperf3による影響調査比較スループット
iperf3x2は、計測用に加え並行してiperf3サーバとクライアントを実行（室温26℃）
macOS MojaveのIKEv2/IPsec VPNスループット計測値（室温24℃）
AES256-SHA256計測データ
AES128-SHA1計測データ
計測結果
AHS256-SHA256: 688Mbps（macOS Mojave標準）
AHS128-SHA1: 827Mbps
下記サイトのIPsecスループット計測では、「AHS128-SHA1」で
「Core i5-7200UのIPsecスループット」が0.93Gbps
「Core i5-7500TのIPsecスループット」が1.11Gbps
「Core i5-8400のIPsecスループット」が1.28Gbps
「Core i7-8700TのIPsecスループット」が1.58Gbps
と計測されている。
CPU毎のCinebench R15/sigle core値を調べてみた。
ベンチマーク値は、「CPU-Monkey」の計測値をリストした。「Core i7-2600」がリストにないが、「Core i7 2600K」のベンチマーク値を記載した（GPUが異なる）。CPUの仕様は、「インテルCore Xシリーズ・プロセッサー・ファミリー」から抽出した。
これらの事からスループット計測に使用した「Core i7-2600」の能力がMacbook proの「Core i7-4850HQ」より若干低く、サーバー側のCPU能力を上げることで「Core i5-7200U」程度のIPsecスループット値計測が推察できる。
Macbook pro（Late 2013 ）仕様
macOS Mojave 10.14.6
Core i7 - 4850HQ （2.3Ghz [3.5]）第4世代
IKEv2 IPsec サーバー（Dell XPS8300）
Debian 10 （Buster）
strongSwan 5.7.2
Core i7 - 2600（3.4Ghz [3.8]） 第2世代
確認したネットワーク構成は下記の通り
「NVR500 L2TP/IPsec VPN最大回線速度計測」と同様に、「192.168.1.0/24」のネットワークに「Debian10」を設置。Debian10は、「firmware-10.0.0-amd64-DVD-1.iso」で基本パッケージ+SSH+WEB + iperf3 + strongswan + libcharon-extra-plugins + resolvconf + dnsutils + net-toolsのルータ構成。ひかり電話HGWからDHCPでIPv4アドレス「192.168.1.57」を設定し、IPv6アドレスはstaticで「2409:10:XXXX:YY00::1:110」を設定した。このIPv6アドレスをドメイン名「vpn.AAAAAAAA.mydns.jp」でDDNSに登録。Debian10の二つ目のEthernetインターフェースにIPv4「192.168.14.1/24」、DHCPv6-PDで得たPrefix「2409:10:XXXX:YY30::/60」からIPv6「2409:10:XXXX:YY30::14:1/64」をそれぞれstatic設定した。
Debian10には、スループット計測用iperf3をサーバ起動させ計測した（手持ちPC不足のため）。
strongSWAN接続端末側の「riightsourceip」は、「192.168.15.0/24」「2409:10:XXXX:YY30::15:0/120」から設定されるよう設計した。
strongSwan設定は、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」と同様とした。
/etc/ipsec.conf
config setup
# strictcrlpolicy=yes
# uniqueids = no
# charondebug="cfg 2,ike 2,esp 2"
conn %default
keyexchange=ikev2
#for Windows10 IKEv2 VPN
ike=aes256-sha256-modp1024
# esp=aes128-sha!
auto=add
left=%any
leftauth=pubkey
leftsubnet=192.168.0.0/20,2409:10:XXXX:YY00::/56,2404:1a8::/32
#for iOS VPN apli
leftsendcert=always
leftcert=debian10-pub.pem
leftid=@vpn.AAAAAAAA.mydns.jp
right=%any
rightsourceip=192.168.15.0/24,2409:10:XXXX:YY30::15:0/120
rightdns=192.168.11.250,2409:10:XXXX:YY10::11:250
conn eap-id-passwd
rightauth=eap-mschapv2
eap_identity=%any/etc/ipse.secrets
: RSA debian10-key.pem "key password"
user1 : EAP "user password"
/etc/strongswan.conf
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
#for iOS/OSX IKEv2 VPN apli
attr {
25 = familyname,flets-east.jp
}
}
}
include strongswan.d/*.conf接続確認
macOS Mojave標準選択ESP暗号化方式
ESP暗号化方式指定「ike=aes128-sha!」
iperf3をIKEv2/IPsecサーバで動作させることによる影響確認
IKEv2/IPsecサーバ上でiperf3を二つ起動させる
iperf3 -s -D -B 192.168.1.57 --logfile iperf3-log-1-57.txt
iperf3 -s -D -B 192.168.14.1 --logfile iperf3-log-14-1.txt
コンソールから「iperf3 -c 192.168.14.1 -t 120」で同一サーバ上でのスループット計測をした場合としない場合でIKEv2/IPsec VPN接続と接続端末から「iperf3 -c 192.168.1.57 -t 60」でスループット計測を行い影響度を確認した。
IPv4 over IKEv2/IPsec over IPv6のMTUを確認
NGN経由のIPv6 IPoEのMTUは、1500。IKEv2/IPsecのMTUは、1406であるが、macOS MojaveのipsecインターフェースのMTUは、1400。
一応確認
接続端末（Macbook pro）からサーバ側へ「ping -s 1372 -c 3 192.168.14.1」（pingデータ長+IPv4(20)+TCP(8)=1400）まで応答がある事を確認
サーバ側からVPN端末へ「ping -s 1372 -c3 192.168.15.1」まで応答がある事を確認
IPv4 over IKEv2/IPsec over IPv6のスループットを計測
iperf3による影響調査比較スループット
iperf3x2は、計測用に加え並行してiperf3サーバとクライアントを実行（室温26℃）
macOS MojaveのIKEv2/IPsec VPNスループット計測値（室温24℃）
AES256-SHA256計測データ
AES128-SHA1計測データ
計測結果
AHS256-SHA256: 688Mbps（macOS Mojave標準）
AHS128-SHA1: 827Mbps
下記サイトのIPsecスループット計測では、「AHS128-SHA1」で
「Core i5-7200UのIPsecスループット」が0.93Gbps
「Core i5-7500TのIPsecスループット」が1.11Gbps
「Core i5-8400のIPsecスループット」が1.28Gbps
「Core i7-8700TのIPsecスループット」が1.58Gbps
と計測されている。
CPU毎のCinebench R15/sigle core値を調べてみた。
ベンチマーク値は、「CPU-Monkey」の計測値をリストした。「Core i7-2600」がリストにないが、「Core i7 2600K」のベンチマーク値を記載した（GPUが異なる）。CPUの仕様は、「インテルCore Xシリーズ・プロセッサー・ファミリー」から抽出した。
これらの事からスループット計測に使用した「Core i7-2600」の能力がMacbook proの「Core i7-4850HQ」より若干低く、サーバー側のCPU能力を上げることで「Core i5-7200U」程度のIPsecスループット値計測が推察できる。
アクセス
トータル
