Azure Virtual Desktop (AVD)接続は、ユーザーがCisco Secure Accessを有効にしてオフィスネットワークからAVDにアクセスすると失敗します。次の特定の動作が確認されました。
AVDは、セキュアアクセスが無効な状態でパーソナルネットワークからアクセスすると正常に動作します。
AVDは、セキュアなアクセスを使用せずにオフィスネットワークからアクセスすると正常に動作します。
セキュアアクセスが有効なネットワークからアクセスされた場合、AVDは機能しません。
この接続障害は、ユーザが仮想デスクトップにアクセスする機能に影響を与え、実稼働の業務にも影響を与えます。パケットキャプチャ分析では、TCPリセットや、セキュアアクセスがAVD接続を終了していたという他のネットワークレベルのインジケータを使用せずに、動作シナリオと非動作シナリオの両方で双方向トラフィックが示されました。
Zero Trust Network Access(ZTNA)を有効にしたCisco Secure Access
すべてのインターネット宛先にZTAを使用するように設定されたZTNAプロファイル
Azure Virtual Desktop (AVD)展開にMicrosoftエンドポイントからアクセス
Secure Accessクライアントを導入したオフィスネットワーク環境
オフィスとパーソナルネットワークの両方からAVDにアクセスするユーザ
この問題は、Microsoft AVD関連のドメインをZTA例外リストに追加することで解決され、セキュアアクセスクライアントはAVDトラフィックでZTNAをバイパスできます。
共同のトラブルシューティング分析により、すべてのインターネットの宛先にZTAを使用するようにZTNAプロファイルが設定されていることが判明しました。これにより、Secure Accessは、Secure Accessクラウドプロキシを介してAVDの継続的なWebSocketトラフィックをルーティングする原因となりました。Azure Virtual Desktopでは、複雑で継続的なトラフィック(WebSocket)を使用してデスクトップセッションをリアルタイムでストリーミングし、クラウドプロキシはストリーミングプロトコルを処理するのではなく、標準のWebページを検査するように設計されているため、この動作によりセッションがドロップされました。
次のMicrosoft AVD関連ドメインがZTA例外リストに追加されました。
*.wvd.microsoft.com
*.core.windows.net
*.servicebus.windows.net
*.events.data.microsoft.com
これらのドメインをZTA例外リストに追加することで、セキュアアクセスクライアントはAVD固有のトラフィックを完全に無視するように指示されました。これにより、AVDトラフィックはMicrosoftに直接送信され、ZTNAプロキシを完全にバイパスします。これは、AVDが正常に機能するためにMicrosoftが必要とするものです。
ZTA例外設定の適用後、監視期間中にAVD接続が正常に動作していると報告されました。ユーザは、セキュアアクセスを有効にして、オフィスネットワークから仮想デスクトップに正常にアクセスできました。
根本的な原因は、Azure Virtual Desktop接続を含む、インターネットに送られるすべてのトラフィックを代行受信したZTNAプロファイル構成でした。AVDのWebSocketトラフィックがSecure Accessクラウドプロキシ経由で検査のためにルーティングされると、接続ドロップが発生します。これは、このプロキシがAVDセッションの連続ストリーミングを処理するように設計されていないためです。AVDでは、安定したデスクトップストリーミングセッションを維持するために、Microsoftエンドポイントに直接接続する必要があります。
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
03-Nov-2026
|
初版 |