Webトラフィックキャッシングに関する別の記事

はじめに、またはなぜWCCPに関する別の記事が必要なのですか？

ハブに関する優れた記事を含む、WCCPプロトコルを使用したWebトラフィックの透過的なキャッシングの組織について多くのことが書かれています。 通常、これらの記事では、左の図に示されているものと同様のスキームが考慮されます。



一見したところ、このソリューションには確かな利点があります。実装は簡単で、キャッシュはユーザーに対して完全に透過的です。プロキシサーバーに障害が発生すると、リクエストは自動的に直接リダイレクトされます。

しかし、WCCPは常にスムーズに進んでいますか？ そうでない場合、新たな問題に対処する方法は？

たとえば、ほとんどすべての記事で、キャッシュサーバーはユーザーと同じセグメントに存在する必要があると記載されていますが、その理由は明記されていません。 しかし、セキュリティポリシーで、すべてのサーバーが境界ネットワーク内にあり、ファイアウォールで保護されている必要がある場合はどうでしょうか。

最近、通信事業者のネットワークにキャッシングサーバーをインストールするときに、同様の要件に対処する必要がありました。その簡略図が右側のタイトル画像に示されています。

読者がそのようなスキームを実装するときに遭遇する問題、および制限を回避する方法に興味がある場合は、歓迎します。

理論-標準および実装機能

まず、少しの理論。 WCCPプロトコルは、（Webだけでなく）トラフィックをリアルタイムでリダイレクトするように設計されています。 プロトコルはもともとシスコによって開発され、その後ほとんどのベンダーが使用するオープンスタンダードになりました。

現在、Internet-Draftのステータスにあり、 draft-mclaggan-wccp-v2rev1-00で記述されているバージョン2 が関連しています。

このプロトコルの動作におけるいくつかの重要な点について説明します（図を参照）。



すべてのWCCPメッセージは、宛先ポート番号が2048のUDPパケットです。メッセージングの順序は次のとおりです。

1. サーバーがトラフィックキャッシング要求を処理する準備ができている場合、WCCP2_HERE_I_AMメッセージを送信します。
2. ルータは、設定に関する情報、特に「Receive ID」フィールドを含むWCCP2_I_SEE_YOUメッセージをサーバーに送信します。
3. 応答するサーバーは、別のメッセージWCCP2_HERE_I_AMを送信します。このメッセージには、前のステップと同じ値を持つ「Receive ID」フィールドが含まれ、ルーターで動作する準備ができていることを確認します。
4. そのようなメッセージを受け取ったルーターは、この時点からWebサイトへのユーザーリクエストをキャッシュサーバーにリダイレクトする必要があることを理解しています。

システムの準備が整いました。 WCCP2_HERE_I_AMおよびWCCP2_I_SEE_YOUメッセージングプロセスは定期的に繰り返され（デフォルトでは10秒ごとに1回）、ルーターがキャッシュサーバーから応答を受信しない場合、後者はプロセスから除外されます。
実際には、プロトコルはやや複雑で、認証、さまざまなリダイレクトアルゴリズムなどを提供しますが、理解を深めるために重要ではない詳細は意識的に省略します。 興味のある読者は、対応するドラフトでそれらを見つけることができます。リンクは上記にあります。

この実装は、ソリューションのフォールトトレランスに貢献します。キャッシングサーバーに障害が発生し、WCCP2_HERE_I_AMメッセージの送信を停止すると、ルーターはパケットの転送の試行を停止し、インターネットへの直接送信を開始します。 サービスが復元されると、WCCP2_HERE_I_AM / WCCP2_I_SEE_YOUメッセージングプロセスが繰り返され、キャッシングスキームが再び機能し始めます。

ユーザーにとって、このような拒否は完全に見えないか、ブラウザにページがリロードされると消える「接続できません」という一時的なメッセージのように見えます。

Wiresharkでは、次の図に示すように、WCCPメッセージングプロセスが表示されます。 [時間]列に注意してください。 トラフィックイメージは実際のシステムから取得されるため、IPアドレスはセキュリティのために切り捨てられます。



クライアントがWebサーバーからデータを取得しようとしたときに何が起こるか見てみましょう。 わかりやすくするために、例で使用するために割り当てられた特別な範囲を使用して特定のIPアドレスをホストに割り当てます。簡単にするために、不要な機能（NAT、ファイアウォールなど）をすべて考慮から除外します。

1. ユーザーブラウザーは、SRC IP 198.51.100.150、DST IP 192.0.2.20、DST TCPポート80、TCP SYNフラグを使用してパケットを送信することにより、TCPセッションを開始します。
2. このようなパケットを受信すると、ルーターはそれをさらにインターネットに送信せず、GREパケットに完全にパックしてキャッシュサーバーに送信します。 GREパケットには、それぞれSRC IP 192.51.100.1とDST IP 198.51.100.100があります。 Wiresharkでは、次の図のようになります。
   
3. このようなパケットを受信すると、キャッシュサーバーはまずこのパケットを処理するかどうかを決定します。 そうでない場合、パケットは同じGREトンネルを介した通常の転送のためにルーターに送り返され、アルゴリズムは終了します。 はいの場合、サーバーは次のステップに進みます。
4. キャッシングサーバーは、Webサーバーとの接続を確立し、そのためにSRC IP 198.51.100.100、DST IP 192.0.2.20、DST TCPポート80、TCP SYNフラグを持つパケットを送信します。
5. それに応じて、Webサーバーは、SRC IP 192.0.2.20、SRC TCPポート80、DST IP 198.51.100.100、TCP SYN / ACKフラグを使用して、つまり、方法握手。
6. Webサーバーから応答を受信するキャッシングサーバーは、次の2つのことを行います。
   
   • SRC IP 198.51.100.100、DST IP 192.0.2.20、DST TCPポート80、ACKフラグを使用してWebサーバーにパケットを送信します。つまり、通常のTCPセッションを継続します。 IPアドレスが198.51.100.100のクライアント。
     
   • SRC IP 192.0.2.20、SRC TCPポート80、DST IP 198.51.100.150、TCP SYN / ACKフラグを使用してWebクライアントにパケットを送信します。つまり、クライアントに対しては、Webサーバーが直接応答したように見えます。 この瞬間を覚えておいてください、それはさらなる理解の鍵です。
   
   
7. したがって、2つのTCPセッションが確立されています。1つはクライアントとキャッシュサーバーの間、もう1つはキャッシュサーバーとWebサーバーの間です。 キャッシュサーバーは、通常の方法でWebサーバーからコンテンツを受信し、クライアントにブロードキャストし、同時にメモリまたは（および）ディスクに保存します。
   その後同じコンテンツにアクセスすると、キャッシュサーバーは、特定の条件に従って、そのWebサーバーを再度ポンプでくみ出すことはできませんが、それ自体でWebクライアントに提供することができます。
   

説明したアルゴリズムを図に概略的に示します。



いくつかの重要な点に注意してください。

1. GREトンネル内のパケットは、主にルーターからキャッシュサーバーに送信されます（キャッシュサーバーがパケットを処理できず、通常の転送のためにルーターに送り返す場合を除く）。
2. 逆方向、つまりキャッシュサーバーからWebクライアントへは、一般的にルーターをバイパスしてパケットが直接送信されます。
3. キャッシングサーバーは、Webクライアントのパケットのアドレスを設定するのではなく、リクエストが行われたWebサイトのアドレスを設定します。

このようなプロトコルの実装により、トラフィックがWebクライアントからWebサーバーにリダイレクトされるだけでよく、通常はその量が少ないため、ルーターの負荷が大幅に削減されます。 通常大量のWebサーバーからのトラフィックは、複雑な処理を受けません-単にルーティングされます。

ただし、このような実装では非対称トラフィックが作成され、次のセクションで説明する複雑さが発生します。

練習-ルーターとファイアウォールとの戦い

前のスキームを変更します-ファイアウォールの背後にキャッシュサーバーを配置します。



Cisco IOSソフトウェアバージョン12.3以降を搭載したCiscoルーター、ソフトウェアバージョン8.2以降を搭載したCisco ASAファイアウォール、Linuxベースのキャッシュサーバー（RHELまたはCentOSディストリビューション）、およびSquidキャッシングソフトウェアを使用することを想定します。
この場合、すべてを構成する方法は？ 基本機能がすでに構成されていると仮定します。つまり、Webクライアントとキャッシュサーバーがインターネット上のリソースにアクセスできるとします。 シスコでWCCPをセットアップすることから始めましょう。

次の2つのアクセスリストを作成する準備作業を実行します。

ip access-list standard l_wccp_service permit 203.0.113.100 ip access-list extended l_wccp_redirect permit tcp host 198.51.100.150 any eq www 

最初は、WCCP2_HERE_I_AMメッセージを受信できるキャッシングサーバーを決定します。
2番目は、キャッシュサーバーにラップする必要があるトラフィックを決定します。

WCCPを構成し、内部ユーザー、つまりアドレス198.51.100.1を対象とするインターフェイスでWCCPを有効にします。 明確にするために、FastEthernet0 / 0とします）：

 ip wccp web-cache redirect-list l_wccp_redirect group-list l_wccp_service interface FastEthernet0/0 ip wccp web-cache redirect in 

ファイアウォールでは、ルーターとキャッシュサーバー間でWCCPおよびGREパケットを交換できます。

 access-list l_wccp extended permit gre host 198.51.100.1 host 203.0.113.100 access-list l_wccp extended permit udp host 198.51.100.1 host 203.0.113.100 access-group l_wccp in interface outside 

キャッシュサーバーを構成します。 まず、squidをインストールして設定します。これには、お気に入りのテキストエディターを使用して/etc/squid/squid.confファイルを開き、次の行が含まれていることを確認します。

 # /etc/squid/squid.conf http_port 3128 transparent wccp2_router 198.51.100.1 wccp2_forwarding_method 1 wccp2_return_method 1 wccp2_assignment_method hash wccp2_service standard 0 

トンネルインターフェイスを作成してみましょう。このインターフェイスでも、お気に入りのエディターで、次の内容のファイル/ etc / sysconfig / network-scripts / ifcfg-tun0を作成します。

 # /etc/sysconfig/network-scripts/ifcfg-tun0 DEVICE=tun0 BOOTPROTO=none ONBOOT=yes TYPE=GRE PEER_OUTER_IPADDR=198.51.100.1 PEER_INNER_IPADDR=192.168.168.1 MY_INNER_IPADDR=192.168.168.2 

IPアドレスPEER_INNER_IPADDRおよびMY_INNER_IPADDRは絶対に任意です。通常の方法では、このトンネルを介して何もルーティングされません。 代わりに、DSTポート80で着信するすべてのTCPトラフィックは、iptablesを使用してsquidでラップされます。 squidがポート3128で応答していると仮定して、トンネルインターフェースを上げ、squidで必要なトラフィックをラップします。

 /etc/sysconfig/network-scripts/ifup tun0 iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 203.0.113.100:3128 /etc/init.d/iptables save 

キャッシュサーバーがルーターに登録されていることを確認します。

 cisco# show ip wccp Global WCCP information: Router information: Router Identifier: 198.51.100.1 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets s/w Redirected: 175623 Process: 0 Fast: 0 CEF: 175623 Redirect access-list: l_wccp_redirect Total Packets Denied Redirect: 113892411 Total Packets Unassigned: 20590 Group access-list: l_wccp_service Total Messages Denied to Group: 26558 Total Authentication failures: 0 Total Bypassed Packets Received: 0 

ここでは、不快な待ち伏せが予想されます。通常、ルーターには、異なるIPアドレスを持つ複数のインターフェイスがあります。 そして、あるインターフェイスのSRC IPからWCCP2_I_SEE_YOUパケットを送信し、別のインターフェイスのSRC IPからGREパケットを送信することを妨げるものは何もありません。
Cisco IOSルーターのファームウェアのすべてのバージョンではありませんが、コマンド「ip wccp source-interface」が提供されます。これにより、IPアドレスがWCCPサブシステムに関連するすべてのパケットのSRC IPとして使用されるインターフェイスをハードセットできます。

ルーターがこのコマンドをサポートしている場合、幸運です。 実行してください：

 ip wccp source-interface FastEthernet 0/0 

そのようなコマンドに応じて、ルーターが「構文エラー」のようなものを生成した場合、次のように進みます-ME、およびキャッシュサーバーでネットワークアナライザー（少なくともtcpdump）で診断を実行し、どのIPアドレスから来たかを調べますWCCPパッケージ、およびGREパッケージ。

次に、squidの設定で、トンネルインターフェースとiptablesの設定で2番目のIPアドレスを指定します。 それに応じて、MEのアクセスリストを変更します。

ルータの後続の再設定中に、インターフェイス間でWCCPパケットが到着するIPアドレスを防ぐために、最後のインターフェイスにループバックインターフェイスを作成できます。 この場合、WCCPはすべてのループバックインターフェイスの中で最大のIPアドレスを使用してパケットを送信します。

 interface lo0 ip address 198.51.100.20 255.255.255.255 

リダイレクトが機能することを確認します。 最初に、以前に作成したアクセスリストのパケット数が増加することを確認します。

 cisco# show access-list l_wccp_redirect Extended IP access list l_wccp_redirect 10 permit tcp host 198.51.100.150 any eq www (2399 matches) 

次に、クライアントマシンのブラウザで任意のWebページを開きます。 そして、確かに何もうまくいかないでしょう。 それを理解しようとすると、ファイアウォールのログでこのタイプに関するメッセージを見つけるでしょう。

 %ASA-4-313004: Denied ICMP type=0, from 192.0.2.20 on interface dmz to 198.51.100.150: no matching session 

Googleで検索しようとすると、最初のリンクから非対称ルーティングに関する情報が得られます。 これが何を意味するかを理解しましょう。
Cisco ASAファイアウォールはステートフルインスペクションデバイスです。つまり、TCP SYN / ACKフラグ付きのパケットをキャッシュサーバーからクライアントに渡すには、まずクライアントからのTCP SYNフラグ付きの対応するパケットが必要です。ウェブサイトに同じMEを進めました。

この場合、MEはクライアントがTCPセッションを開始したことを理解し、適切な内部構造を作成し、このTCPセッションの状態を正しく監視し始めます。

このスキームでは、開始SYNパケットはMEを通過しますa）GREトンネル内とb）「間違った方向にあるかのように」。
したがって、MEは接続テーブルでTCPセッションを開始せず、セッションが開始したことを理解できず、パケットをスキップする必要があります。

そのような状況で何をすべきか？ MEをバイパスしてキャッシュサーバーに接続できない場合、DMZ側から到着するパケットのオープンTCPセッションのチェックを無効にするだけです。

Cisco ASAでは、検証の無効化機能はTCPバイパスと呼ばれます 。 この機能には制限があります。

1. ソフトウェアバージョン8.2以前のCisco ASAでは機能しません。
2. 同じCisco ASAモデルMEでクライアントゾーンとDMZの両方を編成する方法は（少なくとも見つかりませんでした）知られていない-IPアドレス変換は予測どおりに機能しません。

したがって、TCPバイパス機能を有効にします。

 access-list l_bypass extended permit tcp any eq www host 198.51.100.150 class-map c_bypass match access-list l_bypass policy-map p_bypass class c_bypass set connection advanced-options tcp-state-bypass service-policy p_bypass interface dmz 

l_bypassアクセスリストには、クライアントIPアドレスの範囲が必要です。

これですべてが機能するはずです。 少なくともそれは私たちのために働いた。

おわりに

この記事は、小規模な通信事業者のネットワークにWebトラフィックをキャッシュする機能を実装した経験に基づいており、ネットワークエンジニアの仕事における2つの古い原則をもう一度説明しています。

• プロトコルの標準と説明を無視しないでください。
• 何が起こっているのかわからない場合は、怠けずにネットワークアナライザーを接続してください。

テストと実装に成功しました！ そして、今や常にあなたのチャンネルが可能な限り少ないトラフィックを転送するようにします。