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぀の叀い原則をもう䞀床説明しおいたす。





テストず実装に成功したした そしお、今や垞にあなたのチャンネルが可胜な限り少ないトラフィックを転送するようにしたす。



All Articles