2021-06-26 08:02 PM 2021-07-12 10:23 PM 更新
こんにちは
ASA 5545X + OS 9.6系 + AnyConnect 4.6系でエンドユーザにSSL-VPN環境を提供しています。
エンドユーザはWindowsパソコンを使用しています。
(ASAは近いうちに、OS 9.12系 + AnyConnect 4.9 or 4.10 系にVer.Upを予定しています)
Ver.Upにあたりパフォーマンス改善ができないかを考えております。
以前から気になっていたのですが、
・DTLSを使うgroup-policy(ユーザグループ)で接続した時と
・DTLSを使わずにTLSで接続した時で、
通信速度が極端に違うことです。
同じ時間帯に同じASAに、同じインターネット接続環境から接続して
同じスピード測定サイトで測定しても、かなりの差が出ます。
・VPN未接続時:Download速度は60~70Mbps, Upload速度は10Mbps
・DTLS使用時 :Download速度は30Mbps, Upload速度は10Mbps
・TLS使用時 :Download速度は5Mbps, Upload速度は10Mbps
以下を確認しました
■パケットキャプチャでの確認
Wiresharkでモニターすると(インターフェースは、AnyConnectのVAではなく物理アダプタを指定)
TLS使用時は、
・クライアント → サーバ(ASA)のTCP Dupicate ACKや
・クライアント ← サーバ(ASA)のTCP Fast Retransmission
が多発していました。
(これでは遅くても無理がないな、、という感じ)
■MTUの確認
VPNで遅延が目立つ時に疑うものとしてMTUの設定があるかと思いますが
DTLSでもTLSでも、自動調整が働いているようです。
(Windowsのコマンドプロンプトから
netsh interface ipv4 show interfaceで確認しました
結果は以下の通りでした
DTLS:1406 Byte ←group-policyにも設定してある上限値
TLS :1367 Byte ←自動調整した結果と思われます )
TLS接続時に、AnyConnectのVAに対して
netsh interface ipv4 set interfaceコマンドでMTUを
1367から1300,1250などと下げてみましたが効果はありませんでした。
(AnyConnect側で調整せずに、勝手に書き換えて意味があるのか?は置いておくとして・・)
---補足---
・ASA5545X×2台で運用しており、クライアントはほとんどがSSL-VPN接続です(わずかにスマホからIPsec-VPN接続もあり)
・クライアント数はASA5545X 1台あたりの同時接続数は400~500程度です
・ASAのCPU使用率は20~30%でまだ余裕があると思います。
・udp:443が遮断される環境からVPN接続するユーザには、TLSを使うgroup-policy(ユーザグループ)での接続を案内しています
==============================
質問事項
==============================
何か他にないかと思い、調べているとこんな情報がありました
------------------------------------------------------
ASA: リモートアクセスVPN パフォーマンス最適化のためのベストプラクティス (AnyConnect)
https://community.cisco.com/t5/%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3-%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/asa-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9vpn-%E3%83%91%E3%83%95%E3%82%A9%E...
---「ハイエンドモデルのパフォーマンス最適化 」の項の抜粋---
Note: ハイエンドモデルで AnyConnectの SSL接続を多用する場合は チューニングを検討してください
ASA5545/5555/5585や、FPR4100/9300シリーズ(※)などハイエンドモデルでは、専用の高速処理用の暗号処理エンジンを搭載しており、暗号処理エンジンの処理優先度を、IPsec もしくはSSL もしくは Balancedの何れかに変更が可能です。
ASA5545/5555/5585は IPsecがデフォルト、FPR4100/9300シリーズは Balanced がデフォルト値です
例えば、SSL利用が殆どの環境の場合、"crypto engine accelerator-bias ssl"コマンドを実行することで、暗号処理エンジン内のコアが SSL処理優先の割当に切り替わり、AnyConnectのSSL接続時のパフォーマンスを最大化できます。
例えば、SSLと IPsecの処理負荷が同程度の環境の場合は、"crypto engine accelerator-bias balanced"コマンドを実行することで、暗号処理エンジン内のコアが IPsec処理と SSL処理用で半々となり、バランスよく両方の暗号処理が可能になります。
(以下省略)
------------------------------------------------------
私が使っているASA5545Xではデフォルトで運用しているので、IPsecの方が優先度が高くなるようです。
通信量がやや多い時間帯にshow crypto accelerator load-balanceコマンドを打ってみたところ
・コアの割振りは(IPsec用):(SSL用)=5:3でした
・SSL-VPNの処理に関して、3つのコアでの分散具合は、偏りが多い時で75%:20%:5%くらいでした
■質問事項
IPsec/SSL/Balancedで目に見える差が出るかは、「ユーザの環境次第」という面もあるかと思いますが
SSLまたはBalancedに変えたとして、TLS接続時のパフォーマンス改善は期待できるのでしょうか?
-----------------------------
検証環境にはASA 5545Xのようなハイエンド機がなく、設定変更のコマンドは性質上、メンテナンス時間でもない限り
本番環境で試せるものではないため、こちらに書き込みをさせていただきました。
よろしくお願いします。
解決済! 解決策の投稿を見る。
2021-06-29 05:16 PM
こんにちは!
TLSの通信が遅いのは、キャプチャから確認して頂いてますが、TCPベースのリモートVPN接続の場合、TCP特有の確認応答や手間が増えるので、そこでASA/AnyConnect端末や 経路機器で処理遅延が増えて低速化するのが主因かと思います。
VPN系は DTLS/TLSのAnyConnect終端しかASAで使ってない場合は、ハイエンドの場合は深く考えずに"crypto engine accelerator-bias ssl"を有効化して使うようにしてますが(暗号処理時におけるASA内部のボトルネックが減るので それでASA全体のパフォーマンが上がったと嬉しい報告も多数うけてます)、TLSが遅い理由は「暗号処理」"外"の所が主因だと思うので、その場合は高速化はあまり期待できないのではと思います。。たぶん。
2021-06-29 05:16 PM
こんにちは!
TLSの通信が遅いのは、キャプチャから確認して頂いてますが、TCPベースのリモートVPN接続の場合、TCP特有の確認応答や手間が増えるので、そこでASA/AnyConnect端末や 経路機器で処理遅延が増えて低速化するのが主因かと思います。
VPN系は DTLS/TLSのAnyConnect終端しかASAで使ってない場合は、ハイエンドの場合は深く考えずに"crypto engine accelerator-bias ssl"を有効化して使うようにしてますが(暗号処理時におけるASA内部のボトルネックが減るので それでASA全体のパフォーマンが上がったと嬉しい報告も多数うけてます)、TLSが遅い理由は「暗号処理」"外"の所が主因だと思うので、その場合は高速化はあまり期待できないのではと思います。。たぶん。
2021-07-09 06:57 PM 2021-07-12 10:29 PM 更新
Akira Muranakaさん
こんにちは。回答ありがとうございます!
1.本番環境にあるASA5545Xについては、今度のメンテナンス作業時に
crypto engine accelerator-bias ssl コマンドを入れてパフォーマンス改善を図ります!
2.AnyConnectにTLSで接続したときに通信速度が低下する件ですが、
検証機(ASA5506X)でクライアント接続数が1の状態で試しても通信速度が低下するので、crypto engine accelerator-bias ssl による改善とは関係のない話となりそうです。
DTLS接続時と比べてTLS接続時は、クライアントPCからみて、
・ダウンロード方向の通信が極端に遅くなります(DTLSの方が動きが軽いとはいえ差が大きすぎる気がします)
・アップロード方向の通信は特に影響は受けません
最初の書き込みでクライアントPCでのパケットキャプチャについて記載しましたが、他の調べ方が無いかと考えて、show asp dropコマンドで確認してみました。
カウンタ値の中で
「SVC Module is in flow control (mp-svc-flow-control)」が
ダウンロード通信の時にどんどんカウントアップしました。これが関係ありそうです。
-------------------
# show asp drop
Frame drop:
SVC Module is in flow control (mp-svc-flow-control) 4598 ←コレ
No route to host (no-route) 5
Flow is denied by configured rule (acl-drop) 21
First TCP packet not SYN (tcp-not-syn) 15
TCP failed 3 way handshake (tcp-3whs-failed) 1
TCP SEQ in SYN/SYNACK invalid (tcp-seq-syn-diff) 4
Early security checks failed (security-failed) 16
Last clearing: ~
Flow drop:
Flow is denied by access rule (acl-drop) 56
Last clearing: ~
#
------------------------
capture [名前] type asp-drop コマンドでも調べてみましたが
34: 17:43:56.299728 [送信先IP].443 > [送信元IP].61349: P 1013273471:1013273608(137) ack 2092040983 win 30240 Drop-reason: (mp-svc-flow-control) SVC Module is in flow control
と表示されるだけで、新しい情報は得られませんでした
------------------------
SVCモジュールから見た時に、流れ込むデータ量が多すぎるのでドロップが発生した ということのようです。
ということで、次の一手を思案中です。。
エキスパートの回答、ステップバイステップガイド、最新のトピックなどお気に入りのアイデアを見つけたら、あとで参照できるように保存しましょう。
コミュニティは初めてですか?これらのヒントを活用してスタートしましょう。 コミュニティの活用方法 新メンバーガイド