セキュリティ : Cisco Web セキュリティ アプライアンス

WCCP の使用のパスMTU ディスカバリの WSA 動作

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料は設定が Web Cache Communication Protocol (WCCP)およびパス 最大伝送ユニット (MTU) ディスカバリが両方含まれている、問題にソリューションを提供しますときルータがパケットを廃棄するところで直面する問題を記述したものです。

Ivo Sabev によって貢献される、Cisco TAC エンジニア。

背景説明

前フェーズ

別々に検知 されたとき特定の問題を処理するために、多くの機能は優秀です。 2 つか 3 つの手法を結合すれば時々しかし、それは不適切な動作を生成 し、それをきちんとはたらかせます別の機能か回避策をもたらして下さい。 たとえば、スパニングツリーを使用すれば最小デッドインターバルが使用される場合 Open Shortest Path First (OSPF)およびレイヤ2 (L2)統合は OSPF (1s)より(20s)時間がかかりますが、複数スパニング ツリー (MST)とスパニングツリーを取り替え、再度適切に機能します。

同じインターオペラビリティ 動作は WCCP とパスMTU ディスカバリの間で観察されました; 多数はそれが総称ルーティング カプセル化(GRE) ヘッダ問題であると考えます。 ただし、この資料は実質原因を説明したものです。

パスMTU ディスカバリおよび WCCP がどのように別々にはたらくか

Path MTU Discovery

大きいパケットがどのようにのある場合もあるか各行に制限があります。 サポートされるよりより大きいパケットを送信 すれば、廃棄されます。 方法の L3 デバイスのロールの 1 つは(ルータ)エンドツーエンド通信が各行の機能に対して透過的であることを確かめるために行の 1 から他の 1 へ注意およびチョップ大きいパケットを必要とすることです。

時々しかし、エンドホストはパケットが切り刻むことができないように設定されます(たとえば、暗号化ファイル、音声コール)。 この情報は IP ヘッダーの中の Don't Fragment (DF) ビットで伝えられます。 ルータはこれらのようなパケットを廃棄しますが、ルータはインターネット制御メッセージ プロトコル (ICMP) メッセージによってエンドホストに報告することを試みます(到達不能型 3 宛先は 4 つ-必要とされるフラグメンテーション DF ビットが設定をコードします)。 こうすればは、ホストより小さいパケットを将来送信するために確認します。

これはパスMTU ディスカバリの中心です。 DF ビットが設定が付いている大きいパケットを送信できます端の方にそれを作るかどうかまたは見るために以前に記述されているように ICMP レポートを受け取れば。 最大実行可能なパケットサイズを判別したら、あらゆるそれ以上の通信のためにそれを使用して下さい。 詳細については RFC 1191 を参照して下さい。

Web セキュリティ アプライアンス(WSA)はパスMTU ディスカバリをデフォルトで用います。 従って、生成されたパケットにすべてデフォルト 設定によって DF ビットが設定があります。

WCCP

ナレッジ他なしで Webトラフィックにネットワークにセキュリティを課す必要がある場合、目に見えないプロキシによってトラフィックを実行します。 (ルータ/ファイアウォール)およびこの場合 WSA である、/ウェブキャッシュエンジン プロキシ代行受信するデバイスの間で通信するのに使用する WCCP はプロトコルです。

このダイアグラムはこのシナリオかのトラフィックフローどのように説明します:

それはこれのようにはたらきます:

  1. クライアントは IPソース、IP アドレス(クライアントIPアドレス)、および宛先 サーバ IP アドレスの HTTP GET を送信 します。

  2. ファイアウォールかルータは HTTP GET を代行受信し、WCCP GRE か純粋な L2 によって Web cache/WSA にそれを転送します。 ソースは今でもクライアントIPアドレスであり、宛先は今でも Webサーバ IP アドレスです。

  3. WSA は要求を点検し、Webサーバの方に正当なら、それを映します。 ここに宛先 IP アドレスは Webサーバ IP アドレスであり、クライアントIPアドレス スプーフィングを有効に したかどうかソース IP アドレスは WSA またはクライアント、に基づいてであるかもしれません。 この例に関しては、リターントラフィックがいずれの場合も WSA を見つけなければならないので重要ではありません。

  4. リターントラフィックは WSA で検査されます。

  5. WSA はソース IP アドレスのクライアントへの応答を、常に Webサーバ IP アドレス(従ってクライアント 疑わしくなりません)、および destiantion クライアントIPアドレス返します。

問題

ダイアグラムからのルータの 1 つがトラフィックをフラグメント化しなければならない場合何が起こりますか。 WSA はパケット第 5 に DF ビットを置きます、フラグメント化しなければなりません。 ルータはフラグメンテーションが必要であるが、DF ビットが設定 されることをそれを廃棄し、送信側に告げます(ICMP 型 3 は 4)コードします。 結局、RFC 1191 は今はたらかなければなり、送信側はパケットサイズを下げる必要があります。

WCCP を使うと、ソース IP アドレスは Webサーバ IP アドレスです、従ってこの ICMP は WSA に決して行きません; むしろ、それはリアルWebサーバに行くことを試みます(、下部ののこのルータ気づいていません WCCP に覚えて下さい)。 これは WCCP およびパスMTU ディスカバリが時々一緒にネットワーク設計をどのように壊すかです。

解決策

この問題を解決する 4 つの方法があります:

  • 実質 MTU を検出し、次にインターフェイスの MTU を下げるのに WSA の etherconfig を使用して下さい。 IP が 20 である、そしていつ IP ヘッダーに 8 バイトを追加する ICMP を使用することを、こと TCP ヘッダである 60 覚えていて下さい。

  • パスMTU ディスカバリ(pathmtudiscovery CLI WSA コマンド)をディセーブルにして下さい。 これはパフォーマンス問題を引き起こすかもしれない 536 の TCP MSS という結果に終ります。

  • ネットワークをそうそこにです WSA とクライアント間の L3 フラグメンテーション変更しないで下さい。

  • IP TCP を ms 調節します関連するインターフェイスの方法の各 Ciscoルータの 1360 の(または他の計算された数)コマンドを使用して下さい。

その他の注意事項

この問題は調査中の間、幾つかの分のクライアントにプロキシを明示的に 設定 し、次にそれを取除けば、問題は次の 4 から 5 時間の間解決されること検出されました。 これは、明示モードで、WSA とクライアント間のパスMTU ディスカバリ メカニズムがはたらくというファクトが原因です。 WSA がパスMTU を検出すれば、参照用の内部テーブルに検出された TCP MSS と共にそれを保存します。 おそらく時間以降にそれほど再度はたらかないためにソリューションをするこの表は 4 から 5 時間毎にリフレッシュされます。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 118843