内容

はじめに

前提条件

要件

使用するコンポーネント

さまざまなタイプのプロキシ導入

TLSハンドシェイク

HTTP応答コード

1xx：情報

2xx：成功

3xx：リダイレクション

4xxコード：クライアントエラー

5xx：サーバエラー

明示的な展開

認証を使用しない明示的な導入でのHTTPトラフィック

クライアントとSWA

SWAおよびWebサーバ

キャッシュされたデータを持つトラフィック

認証を使用しない明示的な導入でのHTTPトラフィック

クライアントとSWA

SWAおよびWebサーバ

パススルーHTTPSトラフィック

透過的な導入

認証を使用しない透過型導入でのHTTPトラフィック

クライアントとSWA

SWAおよびWebサーバ

キャッシュされたデータを持つトラフィック

認証を使用しない透過型導入でのHTTPトラフィック

クライアントとSWA

SWAおよびWebサーバ

関連情報

はじめに

このドキュメントでは、特にセキュアWebアプライアンス(SWA)に重点を置いた、プロキシ設定ネットワークのネットワークフローについて説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- TCP/IPの基本概念。

- プロキシ設定に関する基本的な知識。

- プロキシを使用する環境で使用される認証メカニズムに関する基礎知識。

この記事では、次の略語を使用します。

TCP:Transmission Control Protocol（伝送制御プロトコル）

UDP:User Datagram Protocol（ユーザデータグラムプロトコル）

IP:Internet Protocol（インターネットプロトコル）

GRE：総称ルーティングカプセル化

HTTP：ハイパーテキスト転送プロトコル。

HTTPS:Hypertext Transfer Protocol Secure（ハイパーテキスト転送プロトコルによるセキュリティ）。

URL:Uniform Resource Locator

TLS:Transport Layer Security（トランスポート層セキュリティ）

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

さまざまなタイプのプロキシ導入

TLSハンドシェイク

HTTPSでのTLSハンドシェイクは、クライアントとサーバがインターネット経由で通信し、セキュアな接続を提供する際に発生します。このプロセスは、通信する2つのアプリケーション間のプライバシーとデータ整合性を維持します。これは、クライアントとサーバが後続のすべての送信に対する暗号化標準とコードに合意する一連の手順を通じて動作します。このハンドシェイクの目的は、第三者による不正なアクセスや操作を防止することです。また、偽装を排除するために、通信相手のIDも認証します。このプロセスは、転送中のデータの安全性を確保するため、HTTPSでは非常に重要です。

TLSハンドシェイクの手順を次に示します。

1. Client Hello：クライアントがhelloメッセージを使用してハンドシェイクプロセスを開始します。このメッセージには、クライアントのTLSバージョン、サポートされている暗号スイート、および「クライアントランダム」と呼ばれるランダムバイト文字列が含まれています。

2. Server Hello：サーバはhelloメッセージで応答します。このメッセージには、サーバが選択したTLSバージョン、選択した暗号スイート、「サーバランダム」と呼ばれるランダムバイト文字列、およびサーバのデジタル証明書が含まれます。必要に応じて、サーバは、相互認証のためにクライアントのデジタル証明書も要求します。

3. クライアントがサーバ証明書を確認する：クライアントは、サーバのデジタル証明書を、それを発行した認証局と照合します。これにより、クライアントが正規のサーバと通信していることが保証されます。

4. プレマスターシークレット：クライアントは「プレマスターシークレット」と呼ばれるランダムなバイト文字列を送信し、セッションキーの作成に使用します。クライアントは、このプレマスターシークレットをサーバ公開キーで暗号化するため、サーバだけが秘密キーで復号化できます。

5. マスターシークレット：クライアントとサーバの両方が、プレマスターシークレットとhelloメッセージのランダムバイト文字列を使用して、同じ「マスターシークレット」を個別に計算します。 この共有秘密がセッションキーを生成する基礎になります。

6. Client Finished：クライアントは「Finished」メッセージをセッションキーで暗号化して送信し、ハンドシェイクのクライアント部分の完了を通知します。

7. Server Finished：サーバは「Finished」メッセージを送信します。このメッセージもセッションキーで暗号化され、ハンドシェイクのサーバ部分の完了を通知します。

HTTP応答コード

1xx：情報

コード

詳細

100継続

通常は、ICAP プロトコル関連の応答です。これは、データの送信を続行できることをクライアントに知らせる情報応答です。ICAPサービス（ウイルススキャンなど）に関しては、サーバは最初のxバイトのみを参照できます。最初のバイトセットのスキャンが完了し、ウイルスを検出しなかった場合、クライアントにオブジェクトの残りの部分の送信を通知するために100 Continueを送信します。

2xx：成功

コード

詳細

200 OK

最も一般的な応答コードです。これは、要求が問題なく成功したことを示します。

3xx：リダイレクト

コード

詳細

301永続的リダイレクション

これは永続的なリダイレクトです。wwwサブドメインにリダイレクトする際に、このコードが表示されます。

302一時リダイレクション

一時的なリダイレクションです。クライアントは、Location：ヘッダーで指定されたオブジェクトに対して新しい要求を作成するように指示されます。

304未変更

GIMS（GET If-modified-since）に対する応答です。これは文字通り、ヘッダーIf-modified-since: <date>を含む標準HTTP GETです。このヘッダーは、クライアントが要求されたオブジェクトのコピーをローカルキャッシュに持っており、オブジェクトがフェッチされた日付を含んでいることをサーバに通知します。その日付以降にオブジェクトが変更されている場合、サーバは200 OKとオブジェクトの新しいコピーで応答します。フェッチされた日付以降にオブジェクトが変更されていない場合、サーバは304 Not Modified応答を返信します。

307認証リダイレクション

これは、透過的なプロキシ導入では、プロキシサーバが要求を認証し、ユーザを認証するために要求を別のURLにリダイレクトするように設定されている場合に最も多く見られます。

4xxコード：クライアントエラー

コード

詳細

400件の不正な要求

これは、HTTP要求が適切な構文に準拠していないため、この要求に関する問題があることを示唆しています。1行に複数のヘッダーがある、ヘッダー内にスペースがある、URIにHTTP/1.1が含まれていない、などの理由が考えられます。正しい構文については、RFC 2616を参照してください。

401不正

Webサーバー認証が必要です

要求されたオブジェクトへのアクセスには認証が必要です。401コードは、ターゲットWebサーバとの認証に使用されます。SWAがトランスペアレントモードで動作し、プロキシで認証が有効である場合、アプライアンスはそれ自体をOCS（元のコンテンツサーバ）であるかのように認識するため、クライアントに401を返します。

使用できる認証方式は、「www-authenticate:」HTTP応答ヘッダーに詳細が記述されています。これにより、サーバがNTLM、基本、またはその他の形式の認証を要求しているかどうかをクライアントに通知します。

403拒否

クライアントは要求されたオブジェクトにアクセスできません。さまざまな理由により、サーバがオブジェクトアクセスを拒否する可能性があります。サーバは通常、HTTPデータまたはHTML応答内に原因の説明を提供します。

404が見つかりません

要求されたオブジェクトがサーバ上にありません。

407プロキシ認証が必要

これは401と同じですが、OCSではなくプロキシに対する認証に特化している点が異なります。この応答が返されるのは、要求が明示的にプロキシに送信された場合のみです。

SWAがトランスペアレントプロキシとして設定されている場合、クライアントはプロキシの存在を認識しないため、407をクライアントに送信することはできません。この場合、クライアントはおそらくTCPソケットをFINまたはRSTします。

5xx：サーバエラー

コード

詳細

501内部サーバエラー

汎用Webサーバーのエラーです。

502不正なゲートウェイ

ゲートウェイまたはプロキシとして動作しているサーバーが受信サーバーから無効な応答を受信したときに発生します。これは、ゲートウェイがアップストリームまたは発信元サーバから不適切な応答を受信したことを示します。

503サービス使用不可

一時的な過負荷またはスケジュールされたメンテナンスが原因で、サーバが現在要求を処理できないことを示します。これは、サーバが一時的にアウトオブサービスになっているが、しばらくすると再び使用可能になる可能性があることを意味します。

504ゲートウェイタイムアウト

クライアントまたはプロキシが、Webページをロードまたはブラウザによる別の要求を実行するためにアクセスしようとしたWebサーバから、タイムリーな応答を受信しなかったことを示します。これは、多くの場合、アップストリームサーバがダウンしていることを意味します。

明示的な展開

Here....

認証を使用しない明示的な導入でのHTTPトラフィック

クライアントとSWA

ネットワークトラフィックは、クライアントのIPアドレスとSWAプロキシインターフェイスのIPアドレスの間で送受信されます（通常はP1インターフェイスですが、プロキシの設定によってはP2または管理インターフェイスになる場合があります）。

クライアントからのトラフィックは、TCPポート80または3128を経由してSWAに到達します（デフォルトのSWAプロキシポートはTCP 80および3128です。この例では、ポート3128を使用します）

- TCPハンドシェイク。

- クライアントからのHTTP Get（宛先IP = SWA IP、宛先ポート= 3128）

- プロキシからのHTTP応答（送信元IP = SWA）

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージクライアントからSWA、HTTP明示的モード

SWAおよびWebサーバ

ネットワークトラフィックは、プロキシのIPアドレスとWebサーバのIPアドレスの間で発生します。

SWAからのトラフィックはTCPポート80を宛先とし、送信元はランダムなポート（プロキシポートではない）です

- TCPハンドシェイク。

- プロキシからのHTTP Get（宛先IP = Webサーバ、宛先ポート= 80）

- WebサーバからのHTTP応答（送信元IP =プロキシサーバ）

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージ：WebサーバへのHTTP-SWA-Explicit-no cache

クライアントからのHTTP Getの例を次に示します

イメージ – SWAへのクライアントHTTP GET – 明示的

これは、クライアントからSWA、Webサーバ、そして最後にクライアントに戻るトラフィックのフロー全体を表します。

イメージ – すべてのトラフィックHTTP明示的 – キャッシュなし

注：トラフィックの各ストリームは異なる色で区別されます。クライアントからSWAへのフローは1色で、SWAからWebサーバへのフローは別の色です。

イメージ – トラフィックフローHTTP明示 – キャッシュなし

アクセスログの例を次に示します。

1706172876.686 224 10.61.70.23 TCP_MISS/200 1721 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",61.46,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 10, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 108, Request Header = 0, Request to Server = 0, 1st byte to client = 3, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 106, Response header = 0, Server response = 1, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 2, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 4; "25/Jan/2024:09:54:36 +0100" ][Client Port = 65238, Server IP = 10.184.216.34, Server Port = 80]

キャッシュされたデータを持つトラフィック

これは、データがSWAキャッシュにある場合の、クライアントからSWAへのトラフィックのフロー全体を表します。

イメージ：HTTP明示的にキャッシュされたデータ

注：ご覧のように、WebサーバはHTTP応答304：キャッシュは変更されていません(HTTP response 304: Cache not Modified)を返します。（この例では、パケット番号1947）

イメージ：キャッシュを使用した明示的なフローHTTP

HTTP応答304の例を次に示します

イメージ：HTTP明示的304応答

アクセスログの例を次に示します。

1706173001.489 235 10.61.70.23 TCP_REFRESH_HIT/200 1721 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",58.59,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 150, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 110, Request Header = 0, Request to Server = 0, 1st byte to client = 2, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 119, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 1; "25/Jan/2024:09:56:41 +0100" ][Client Port = 55709, Server IP = 10.184.216.34, Server Port = 80]

認証を使用しない明示的な導入でのHTTPトラフィック

クライアントとSWA

ネットワークトラフィックは、クライアントのIPアドレスとSWAプロキシインターフェイスのIPアドレスの間で送受信されます（通常はP1インターフェイスですが、プロキシの設定によってはP2または管理インターフェイスになる場合があります）。

クライアントからのトラフィックは、TCPポート80または3128を経由してSWAに到達します（デフォルトのSWAプロキシポートはTCP 80および3128です。この例では、ポート3128を使用します）

- TCPハンドシェイク。

- クライアントからのHTTP CONNECT（宛先IP = SWA、宛先ポート= 3128）

- プロキシからのHTTP応答（送信元IP = SWA）

- Client HelloとURLのSNI（送信元IP =クライアント）

- Server Hello（送信元IP = SWA）

- サーバキー交換（送信元IP = SWA）

- クライアントキー交換（送信元IP =クライアント）

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージ – SWAへのHTTPSクライアント – 明示的 – キャッシュなし

Server Name Indication(SNI)でWebサーバのURLを確認できるように、クライアントからSWAへのClient Helloの詳細を次に示します。この例では、www.example.comであり、クライアントは17個の暗号スイートをアドバタイズしています。

イメージ – HTTPSクライアントhello – 明示的 – SWAへのクライアント

ヒント：このフィルタをWiresharkで使用して、URL/SNI :tls.handshake.extensions_server_name == "www.example.com"を検索できます。

次に、SWAがクライアントに送信した証明書の例を示します

イメージ – HTTPS証明書 – 明示的 – クライアントへのSWA

SWAおよびWebサーバ

ネットワークトラフィックは、プロキシのIPアドレスとWebサーバのIPアドレスの間で発生します。

SWAからのトラフィックは、TCPポート443（プロキシポートではない）宛てです

- TCPハンドシェイク。

- クライアントHello（宛先IP = Webサーバ、宛先ポート= 443）

- Server Hello（送信元IP = Webサーバ）

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージ – HTTPS – 明示的 – WebサーバへのSWA

SWAからWebサーバへのClient Helloの詳細を次に示します。これは、SWAが12の暗号スイートをアドバタイズしたためです。

イメージ – HTTPSクライアントHello - WebサーバへのSWA – キャッシュなし

注：ここで観察された暗号スイートは、クライアントからSWAへのClient Helloの暗号スイートとは異なります。これは、このトラフィックを復号化するように設定されたSWAが独自の暗号を使用するためです。

ヒント:SWAからWebサーバへのサーバキー交換では、Webサーバ証明書が表示されます。ただし、アップストリームプロキシがSWAの設定を検出すると、Webサーバ証明書の代わりに証明書が表示されます。

クライアントからのHTTP CONNECTのサンプルを次に示します。

イメージ：クライアントHTTP接続

これは、クライアントからSWA、Webサーバ、そして最後にクライアントに戻るトラフィックのフロー全体を表します。

イメージ：フルHTTPS明示的 – キャッシュなし

注：トラフィックの各ストリームは異なる色で区別されます。クライアントからSWAへのフローは1色で、SWAからWebサーバへのフローは別の色です。

イメージ – HTTPSフロー – 明示的 – キャッシュなし

アクセスログの例を次に示します。

1706174571.215 582 10.61.70.23 TCP_MISS_SSL/200 39 CONNECT tunnel://www.example.com:443/ - DIRECT/www.example.com - DECRYPT_WEBCAT_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"IW_ref",-,"-","Reference","-","Unknown","Unknown","-","-",0.54,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 1600, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 113, Request Header = 0, Request to Server = 0, 1st byte to client = 113, Response Header = 0, Client Body = 79 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 344, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 0, AMP total = 0; Latency = 0; "25/Jan/2024:10:22:51 +0100" ][Client Port = 24953, Server IP = 10.184.216.34, Server Port = 443]

1706174571.486 270 10.61.70.23 TCP_MISS_SSL/200 1106 GET https://www.example.com:443/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",32.77,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 1630, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 3, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 264, Response header = 0, Server response = 2, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 1, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 2; "25/Jan/2024:10:22:51 +0100" ][Client Port = 24953, Server IP = 10.184.216.34, Server Port = 443]

注：HTTPSトラフィックの透過型導入で確認できるように、アクセスログに2行あります。最初の行はトラフィックが暗号化されている場合を示し、CONNECTと表示されます。WebサーバのURLはtunnel://で始まります。SWAでDecryptionが有効になっている場合は、2行目にGETが含まれ、URL全体がHTTPSで始まります。これは、トラフィックが復号化されたことを意味します。

パススルーHTTPSトラフィック

トラフィックをパススルーするようにSWAを設定した場合のフロー全体を次に示します。

イメージ – HTTPSパススルー – 明示的 – フロー

SWAからWebサーバへのClient Helloのサンプルを次に示します。

イメージ – HTTPSパススルー – 明示的 – WebサーバへのSWA – クライアントhello

これは、クライアントからSWAへのClient Helloと同じです。

イメージ – HTTPSパススルー – 明示的 – SWAへのクライアント – Client hello

次にアクセスログの例を示します。

1706185288.920 53395 10.61.70.23 TCP_MISS/200 6549 CONNECT tunnel://www.example.com:443/ - DIRECT/www.example.com - PASSTHRU_WEBCAT_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"IW_ref",-,"-","Reference","-","Unknown","Unknown","-","-",0.98,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 210, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 233, Request Header = 0, Request to Server = 0, 1st byte to client = 119, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 436, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 22, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 0, AMP total = 0; Latency = 22; "25/Jan/2024:13:21:28 +0100" ][Client Port = 59939, Server IP = 10.184.216.34, Server Port = 443]

注：ご覧のように、これは1行のみで、アクションはPASSTHRUです。

透過的な導入

認証を使用しない透過型導入でのHTTPトラフィック

クライアントとSWA

ネットワークトラフィックは、クライアントのIPアドレスとWebサーバのIPアドレスの間を移動します。

クライアントからのトラフィックはTCPポート80（プロキシポートではない）宛てです。

- TCPハンドシェイク。

- クライアントからのHTTP Get（宛先IP = Webサーバ、宛先ポート= 80）

- プロキシからのHTTP応答（送信元IP = Webサーバ）

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージ – クライアントからプロキシ – HTTP – 透過 – 認証なし

クライアントからのHTTP Getの例を次に示します

イメージ – クライアントからプロキシ – HTTP – トランスペアレント – 認証なし – クライアントHTTP Get

SWAおよびWebサーバ

ネットワークトラフィックは、プロキシのIPアドレスとWebサーバのIPアドレスの間で発生します。

SWAからのトラフィックは、TCPポート80（プロキシポートではない）宛てです

- TCPハンドシェイク。

- プロキシからのHTTP Get（宛先IP = Webサーバ、宛先ポート= 80）

- WebサーバからのHTTP応答（送信元IP =プロキシサーバ）

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージ – プロキシとWebサーバ – HTTP – 透過 – 認証なし

プロキシからのHTTP Getの例を次に示します

イメージ – Webサーバへのプロキシ – HTTP – トランスペアレント – 認証なし – プロキシHTTP Get

これは、クライアントからSWA、Webサーバ、そして最後にクライアントに戻るトラフィックのフロー全体を表します。

イメージ – トラフィック合計 – HTTP – トランスペアレント – 認証なし

注：トラフィックの各ストリームは異なる色で区別されます。クライアントからSWAへのフローは1色で、SWAからWebサーバへのフローは別の色です。

イメージ：WCCP HTTPフロー

アクセスログの例を次に示します。

1702318427.181 124 192.168.1.10 TCP_MISS/200 1787 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",115.29,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 50, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 1, Request Header = 0, Client Body = 0, 1st response byte = 124, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 124>, AMP total = 124<; Latency = 1; "11/Dec/2023:19:13:47 +0100" ][Client Port = 54468, Server IP = 10.184.216.34, Server Port = 80]

キャッシュされたデータを持つトラフィック

これは、データがSWAキャッシュにある場合の、クライアントからSWAへのトラフィックのフロー全体を表します。

イメージ – キャッシュ – 総トラフィック – HTTP – トランスペアレント – 認証なし

注：ご覧のように、WebサーバはHTTP応答304：キャッシュは変更されていません(HTTP response 304: Cache not Modified)を返します。（この例では、パケット番号27）

HTTP応答304の例を次に示します

イメージ – キャッシュ – HTTP応答304 - HTTP – トランスペアレント – 認証なし

アクセスログの例を次に示します。

1702318789.560 105 192.168.1.10 TCP_REFRESH_HIT/200 1787 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",136.15,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 360, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 2, Request Header = 0, Client Body = 0, 1st response byte = 104, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 105>, AMP total = 105<; Latency = 2; "11/Dec/2023:19:19:49 +0100" ][Client Port = 54487, Server IP = 10.184.216.34, Server Port = 80]

認証を使用しない透過型導入でのHTTPトラフィック

クライアントとSWA

ネットワークトラフィックは、クライアントのIPアドレスとWebサーバのIPアドレスの間を移動します。

クライアントからのトラフィックはTCPポート443（プロキシポートではない）宛てです。

- TCPハンドシェイク。

- TLSハンドシェイククライアントHello - Server Hello - Server Key Exchange - Client Key Exchange

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージ – クライアントからプロキシ – HTTP – トランスペアレント – 認証なし

Server Name Indication(SNI)で確認できるように、クライアントからSWAへのClient Helloについて詳しく説明します。この例では、WebサーバのURLはwww.example.comです。

イメージ – Client Hello – クライアントからプロキシ – 透過 – 認証なし

ヒント:Wiresharkでこのフィルタを使用して、URL/SNI(tls.handshake.extensions_server_name == "www.example.com")を検索できます。

次に、サーバキー交換の例を示します

イメージ – サーバキー交換 – クライアントからプロキシ – 透過 – 認証なし

注：確認できるように、証明書は復号化証明書としてSWAで設定された証明書です。

SWAおよびWebサーバ

ネットワークトラフィックは、プロキシのIPアドレスとWebサーバのIPアドレスの間で発生します。

SWAからのトラフィックは、TCPポート443（プロキシポートではない）宛てです

- TCPハンドシェイク。

- TLSハンドシェイククライアントHello - Server Hello - Server Key Exchange - Client Key Exchange

- データ転送

- TCP接続の終了（4ウェイハンドシェイク）

イメージ – Webサーバへのプロキシ – HTTP – トランスペアレント – 認証なし

SWAからWebサーバへのClient Helloのサンプルを次に示します

イメージ – Client Hello - Webサーバへのプロキシ – 透過 – 認証なし

注：ここで観察された暗号スイートは、クライアントからSWAへのClient Helloの暗号スイートとは異なります。これは、このトラフィックを復号化するように設定されたSWAが独自の暗号を使用するためです。

ヒント:SWAからWebサーバへのサーバキー交換では、Webサーバ証明書が表示されます。ただし、アップストリームプロキシがSWAの設定を検出すると、Webサーバ証明書の代わりに証明書が表示されます。

アクセスログの例を次に示します。

1702319784.943 558 192.168.1.10 TCP_MISS_SSL/200 0 TCP_CONNECT 10.184.216.34:443 - DIRECT/www.example.com - DECRYPT_ADMIN_DEFAULT_ACTION_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",0.00,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 940, User Agent = -, AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 50 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 45, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 249, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 5, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 558>, AMP total = 558<; Latency = 50; "11/Dec/2023:19:36:24 +0100" ][Client Port = 54515, Server IP = 10.184.216.34, Server Port = 443]

1702319785.190 247 192.168.1.10 TCP_MISS_SSL/200 1676 GET https://www.example.com:443/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",54.28,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 960, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 50, Response Header = 50, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 97, Client Body = 0, 1st response byte = 48, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 247>, AMP total = 247<; Latency = 97; "11/Dec/2023:19:36:25 +0100" ][Client Port = 54515, Server IP = 10.184.216.34, Server Port = 443]

注：HTTPSトラフィックの透過型導入で確認できるように、アクセスログに2行あります。最初の行は、トラフィックが暗号化された時点、TCP_CONNECT、およびWebサーバのIPアドレスが表示されています。SWAで復号が有効になっている場合、2行目にはGETが含まれ、URL全体がHTTPSで始まります。これは、トラフィックが復号され、SWAでURLが認識されていることを意味します。

関連情報

- テクニカル サポートとドキュメント - Cisco Systems

- アクセスログのパフォーマンスパラメータの設定 – Cisco