[好文共享]《Squid 中文權威指南》第9章譯者：彭勇華

←手機掃碼閱讀火星人 @ 2014-03-04 , reply:0

[好文共享]《Squid 中文權威指南》第9章譯者：彭勇華

譯者序：
本人在工作中維護著數台Squid 伺服器，多次參閱Duane Wessels（他也是Squid 的創始人）的這本書，原書名是"Squid: The Definitive Guide"，由O'Reilly 出版。我在業餘時間把它翻譯成中文，希望對中文Squid 用戶有所幫助。對普通的單位上網用戶，Squid 可充當代理伺服器；而對Sina,NetEase 這樣的大型站點，Squid 又充當WEB 加速器。這兩個角色它都扮演得異常優秀。窗外繁星點點，開源的世界亦如這星空般美麗，而Squid 是其中耀眼的一顆星。
對本譯版有任何問題，請跟我聯繫，我的Email是：yonghua_peng@yahoo.com.cn  彭勇華
--------------------------------------------------------------------------------------

第9章 Cache攔截

Cache攔截是讓傳輸流向Squid的流行技術，它不用配置任何客戶端。你可以配置路由器或交換機將HTTP連接轉發到squid運行的主機。squid運行的操作系統被配置成接受外部數據包，並將其遞交給squid進程。為了讓HTTP攔截生效，你必須配置3個獨立的因素：網路設備，squid運行的操作系統，和squid自身。
<ww-01>;

（譯者註：Cache攔截實際上指的是Squid的透明代理）

9.1它如何工作？

Cache攔截包含了某些網路欺騙，它對理解在客戶端和Squid之間的會話有用。我使用圖9-1和如下的tcpdump示例輸出，來解釋當數據包通過網路時，如何被攔截。

1.用戶代理(user-agent)想請求某個資源，它對原始伺服器發起index.html請求，例如：www.oreilly.com。它需要原始伺服器的IP地址，所以先發起一個DNS請求：

Packet 1
TIME: 19:54:41.317310
UDP: 206.168.0.3.2459 ->; 206.168.0.2.53
DATA: .d...........www.oreilly.com.....
---------------------------------------------------------------------------

Packet 2
TIME: 19:54:41.317707 (0.000397)
UDP: 206.168.0.2.53 ->; 206.168.0.3.2459
DATA: .d...........www.oreilly.com.............PR.....%........PR.
      ....$........PR...ns1.sonic.net.........PR...ns2.Q........PR
      ...ns...M...............h.............!.z.......b......

2.現在有了IP地址，用戶代理初始化到原始伺服器80埠的TCP連接：

Packet 3
TIME: 19:54:41.320652 (0.002945)
TCP: 206.168.0.3.3897 ->; 208.201.239.37.80 Syn
DATA: <No data>;

3.路由器或交換機注意到目的地址是80埠的TCP SYN包。下一步會發生什麼依賴於特定的攔截技術。在4層交換和路由策略上，網路設備簡單的將TCP包轉發到Squid的數據鏈路地址。當squid直接掛在網路設備上時，就這樣工作。對WCCP來說，路由器封裝TCP包為GRE包。因為GRE包有它自己的IP地址，它可能被通過多個子網進行路由。換句話說，WCCP不要求squid直接掛在路由器上。

4.Squid主機的操作系統接受到攔截包。對4層交換來說，TCP/IP包並沒有改變。

假如包使用了GRE封裝，主機會剝離外部的IP和GRE頭部，並將原始的TCP/IP包放在輸入隊列里。

注意squid主機接受到的包是針對外部地址的（原始伺服器的）。正常情況下，這個包不匹配任何本地地址，它會被丟棄。為了讓主機接受外部數據包，你必須在大多數操作系統上激活IP轉發。

5.客戶端的TCP/IP包被包過濾代碼處理。數據包必須匹配某個規則，該規則指示內核轉交這個包給squid。如果沒有這樣的規則，內核簡單的將包按照它自己的方式轉發給原始伺服器，這不是你想要的。

注意SYN包的目的埠是80，但squid可能偵聽在不同的埠，例如3128。包過濾規則允許你改變埠號。你不必讓squid偵聽在80埠。通過tcpdump，你能見到這步，因為轉發的包不會再次通過網路介面代碼。

即使squid偵聽在80埠，包過濾器的重定向規則仍是必要的。可以讓squid不在這些埠上接受攔截包。重定向規則有點神奇，它轉交外部數據包給squid。

6.Squid接受到新連接的通知，它接受這個連接。內核發送SYN/ACK包返回給客戶端：

Packet 4
TIME: 19:54:41.320735 (0.000083)
TCP: 208.201.239.37.80 ->; 206.168.0.3.3897 SynAck
DATA: <No data>;

就象你見到的一樣，源地址是原始伺服器，儘管這個包不會抵達原始伺服器。操作系統只是簡單的將源地址和目的地址交換一下，並將它放進響應數據包里。

7.用戶代理接受到SYN/ACK包，建立起完整的TCP連接。用戶代理現在相信它是連接到原始伺服器，所以它發送HTTP請求：

Packet 5
TIME: 19:54:41.323080 (0.002345)
TCP: 206.168.0.3.3897 ->; 208.201.239.37.80 Ack
DATA: <No data>;
---------------------------------------------------------------------------
Packet 6
TIME: 19:54:41.323482 (0.000402)
TCP: 206.168.0.3.3897 ->; 208.201.239.37.80 AckPsh
DATA: GET / HTTP/1.0
      User-Agent: Wget/1.8.2
      Host: www.oreilly.com
      Accept: */*
      Connection: Keep-Alive

8.Squid接受HTTP請求。它使用HTTP Host頭部來轉換局部URL為完整的URL。在這種情形下，可在access.log文件里見到http://www.oreilly.com。

9.從這點開始，squid正常的處理請求。一般cache命中會立刻返回。cache丟失會轉發到原始伺服器。

10.最後，是squid從原始伺服器接受到的響應：

Packet 8
TIME: 19:54:41.448391 (0.030030)
TCP: 208.201.239.37.80 ->; 206.168.0.3.3897 AckPsh
DATA: HTTP/1.0 200 OK
      Date: Mon, 29 Sep 2003 01:54:41 GMT
      Server: Apache/1.3.26 (Unix) PHP/4.2.1 mod_gzip/1.3.19.1a mo
      d_perl/1.27
      P3P: policyref="http://www.oreillynet.com/w3c/p3p.xml",CP="C
      AO DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa CONo OUR
      DELa PUBi OTRa IND PHY ONL UNI PUR COM NAV INT DEM CNT STA P
      RE"
      Last-Modified: Sun, 28 Sep 2003 23:54:44 GMT
      ETag: "1b76bf-b910-3ede86c4"
      Accept-Ranges: bytes
      Content-Length: 47376
      Content-Type: text/html
      X-Cache: MISS from www.oreilly.com
      X-Cache: MISS from 10.0.0.1
      Connection: keep-alive

不應該讓交換機或路由器來攔截squid到原始伺服器的連接。假如這種情況發生，squid結束與自己的會話，並且不能滿足任何cache丟失。防止這類轉發死循環的最好方法是，確認用戶和squid連接到交換機或路由器的獨立介面。無論何時，應該在指定介面上應用攔截規則。最明顯的，不該在squid使用的介面上激活攔截。

9.2為何要（或不要）攔截？

許多單位發現，cache攔截很有用，因為他們不能，或不願意配置所有用戶的web瀏覽器。相對於配置成百上千台工作站來說，在單個交換機或路由器上做一點網路欺騙更容易。從我們面臨的許多選擇來看，cache攔截確實有好也有壞。它可能讓你的生活更容易，但也許會更難。

Cache攔截的最明顯的貢獻是，所有HTTP請求通過squid自動離開你的網路。你不必擔心配置任何瀏覽器，用戶可能在瀏覽器上禁止他們的代理設置。cache攔截讓網路管理員完全控制HTTP會話。你可以改變，增加，或刪除squid的緩存，而不會顯著影響你的用戶上網衝浪。

關於HTTP攔截的主要不利點就是該技術違背了TCP/IP的標準。這些協議要求路由器或交換機轉發TCP/IP包到目的IP地址里指定的主機。然而轉發包到cache代理破壞了這些規則。代理偽裝身份接受轉交過來的連接。用戶代理被欺騙了，以為它們在與真正的web伺服器會話。

這樣的混亂導致在老版本的Microsoft IE瀏覽器中產生嚴重問題。瀏覽器的Reload按鈕是刷新HTML頁面的最容易的方法。當瀏覽器被配置成使用cache代理時，reload請求包含了一個Cache-Control:no-cache頭部，它強迫產生cache丟失（或cache確認），並確保響應是最近更新的。假如沒有明確配置使用代理，瀏覽器會忽略該頭部。當使用cache攔截時，瀏覽器認為它在連接到原始伺服器，因此沒必要發送該頭部。在這種情形下，squid不會告知用戶的Reload按鈕，也許不會驗證cache響應。squid的ie_refresh提供了解決此bug的局部解決方法（見附錄A）。Microsoft已經在其IE 5.5 SP1中解決了這個問題。

因為類似的理由，你不能結合cache攔截使用HTTP代理驗證。因為客戶端不知道這個代理，它不會發送必要的Proxy-Authorization頭部。另外，407（代理驗證請求）響應代碼也不恰當，因為響應看起來象來自原始伺服器，原始伺服器從來不會發送如此響應。

也不能在cache攔截中使用RFC 1413 ident查詢（見6.1.2.11章節）。Squid不能對必要的IP地址建立新的TCP Socket連接。操作系統在轉發攔截連接到squid時，它執行欺騙。然後，當squid希望bind新的TCP Socket到外部IP地址時，它不能執行欺騙。它想bind的地址實際上並非真正本地的，所以bind系統調用失敗。

cache攔截也與設計成阻止地址欺騙的IP過濾衝突（見RFC 2267:Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source AddressSpoofing）。考慮如圖9-2顯示的網路。路由器有2個LAN介面:lan0和lan1。網路管理員在路由器上使用包過濾器，以確保沒有內部主機傳送假冒源地址的數據包。路由器只會轉發源地址對應相連網路的數據包。包過濾規則也許看起來如下：

# lan0
allow ip from 172.16.1.0/24 to any via lan0
deny ip from any to any via lan0

# lan1
allow ip from 10.0.0.0/16 to any via lan1
deny ip from any to any via lan1

現在看看，當路由器和lan1中的squid主機配置成攔截來自lan0中的HTTP連接后，會發生什麼。Squid裝扮成原始伺服器，這意味著從squid到用戶的響應TCP包欺騙了源地址。lan0過濾規則導致路由器拒絕這些包。為了讓cache攔截生效，網路管理員須移除lan0規則。這樣就讓網路有漏洞，從而易遭拒絕服務攻擊。

我在先前的章節里描述過，客戶端在打開連接之前必須先進行DNS查詢。在某些防火牆環境中，這樣做可能有問題。你想進行HTTP攔截的主機必須能夠查詢DNS。如果客戶端了解自己正使用代理（因為手工配置或代理自動配置），它通常就不去解析主機名。代替的，它簡單的將完整URL轉發給squid，由squid來查詢原始伺服器的IP地址。

另一個小問題是，squid接受任意目的IP地址的連接。例如，某個web站點當機了，但它仍然有DNS記錄存在。squid偽裝這個站點接受TCP連接。客戶端會認為該站點仍然在運行，因為連接有效。當squid連接到原始伺服器失敗時，它強迫返回錯誤消息。

萬一形勢不清，HTTP攔截在初次使用時有些棘手或困難。許多不同的組件必須組合工作，並且要配置正確。甚至，從內存中恢復整個配置也很困難。我強烈建議你在將其應用於生產環境之前，先建立測試環境。一旦你讓它正常運行，請記錄每一步細節。

9.3 網路設備

現在你了解了cache攔截的相關細節，讓我們看看如何實際讓它工作。我們先配置網路設備，它們用來攔截HTTP連接。

9.3.1 內置Squid

在該配置中，你無需交換或網路路由設備來攔截HTTP連接。代替的，squid運行的Unix系統，也就是路由器（或網橋），請見圖9-2。
<ww-02>;

該配置本質上跳過了9.1章的頭三步。squid主機充當網路路由器，它接受HTTP連接包。假如你採用此方法，請直接跳到9.4章。

9.3.2 四層交換

許多單位使用四層交換機來支持HTTP攔截。這些產品提供更多的功能，例如健壯性檢測和負載均衡。我在這裡僅僅講講攔截。關於健壯性檢測和負載均衡的信息，請見O'Reilly's Server Load Balancing and Load Balancing Servers, Firewalls, and Caches (John Wiley & Sons). 下面的章節包含了許多產品和技術的示例配置。

9.3.2.1 Alteon/Nortel

下面的配置來自ACEswitch 180和Alteon's WebOS 8.0.21。網路設置請見圖9-4。
<ww-03>;

客戶端連接到埠1，通過埠2連接到網際網路，squid運行在埠3。下面的行是交換機的/cfg/dump命令的輸出。你無須敲入所有這些行。甚至，在Alteon的新版軟體里，某些命令可能改變了。注意Alteon把這個功能叫做Web Cache重定向（WCR）。如下是處理步驟：

1.首先，你必須分配給Alteon交換機一個IP地址。這是必要的，以便交換機能檢查squid的存活狀態。

/cfg/ip/if 1
      ena
      addr 172.16.102.1
      mask 255.255.255.0
      broad 172.16.102.255

2.Alteon的WCR屬於服務負載均衡(SLB)配置。所以，必須使用如下命令在交換機上激活SLB功能：

/cfg/slb
      on

3. 現在，用squid的IP地址定義real server:

/cfg/slb/real 1
      ena
      rip 172.16.102.66

4. 必須定義一個組，並分配給real server一個組號：

/cfg/slb/group 1
      health tcp
      add 1

5. 下一步定義2個過濾規則。第1條規則匹配HTTP連接（目的埠是80的TCP包），並重定向它們到組1里的server。第2條規則匹配所有其他數據包，並正常轉發它們。

/cfg/slb/filt 1
      ena
      action redir
      sip any
      smask 0.0.0.0
      dip any
      dmask 0.0.0.0
      proto tcp
      sport any
      dport http
      group 1
      rport 0

/cfg/slb/filt 224
      ena
      action allow
      sip any
      smask 0.0.0.0
      dip any
      dmask 0.0.0.0
      proto any

6. 最後一步是給SLB配置指定的交換埠。在埠1上，處理客戶端連接（這也是客戶端連接的埠），並增加2條過濾規則。在埠2上，僅須配置它正常服務（例如，向上連接到Internet）：

cfg/slb/port 1
      client ena
      filt ena
      add 1
      add 224

/cfg/slb/port 2
      server ena

為了驗證HTTP攔截配置正確並工作良好，你可以使用/stats/slb和/info/slb菜單里的命令。/info/slb/dump是快速有效的查看整個SLB配置的方法：

>;>; Main# /info/slb/dump

Real server state:
  1: 172.16.102.66, 00:c0:4f:23:d7:05, vlan 1, port 3, health 3, up

Virtual server state:

Redirect filter state:
  1: dport http, rport 0, group 1, health tcp, backup none
real servers:
   1: 172.16.102.66, backup none, up

Port state:
  1: 0.0.0.0, client
   filt  enabled, filters: 1 224
  2: 0.0.0.0, server
   filt disabled, filters: empty
  3: 0.0.0.0
   filt disabled, filters: empty

在該輸出里，注意到交換機顯示Squid在埠3上可到達，並且運行正常。你也能見到過濾規則1應用到埠1。在埠狀態節里，埠1定義為客戶端連接埠，埠2簡單的標記為服務埠。

/stats/slb/real命令顯示real server(squid)的有用統計：

>;>; Main# /stats/slb/real 1
------------------------------------------------------------------

Real server 1 stats:
Health check failures:             0
Current sessions:                   41
Total sessions:                   760
Highest sessions:                   55
Octets:                            0

大部分統計與任務（例如TCP連接）數量相關。假如再次運行該命令，總共的任務計數會增加。

最後，/stats/slb/group命令顯示幾乎同樣的信息：

>;>; Main# /stats/slb/group 1
------------------------------------------------------------------

Real server group 1 stats:

                  Current    Total  Highest
Real IP address    Sessions Sessions Sessions          Octets
---- --------------- -------- ---------- --------  ---------------
1 172.16.102.66       65    2004    90             0
---- --------------- -------- ---------- --------  ---------------
                        65    2004    90             0

假如不止1個real server在組裡，該輸出會更有趣。

9.3.2.2 Foundry

下面的配置示例來自ServerIron XL，運行的軟體版本是07.0.07T12。跟前面一樣，客戶端在埠1，Internet連接在埠2，squid運行在埠3。然而，這樣的配置少了點東西，因為這裡可以激活HTTP全局攔截。Foundry的cache攔截的名字叫做Transparent Cache Switching（TCS）。請參考圖9-4。
<ww-04>;

首先請給交換機分配1個IP地址，以便執行健壯性檢測：
ip address 172.16.102.1 255.255.255.0

Foundry允許你在特定埠上激活或禁用TCS。然而簡單起見，這裡全局激活它：
ip policy 1 cache tcp http global

在該行里，cache是針對TCS功能的關鍵字。下1行定義web cache，我定義其名字為squid1，並且告訴交換機它的IP地址：
server cache-name squid1 172.16.102.66

最後的步驟是將web cache加進cache組裡：
server cache-group 1
cache-name squid1

假如在轉發連接時有問題，請參閱show cache-group命令的輸出：

ServerIron#show cache-group

Cache-group 1 has 1 members Admin-status = Enabled Active = 0

Hash_info: Dest_mask = 255.255.255.0 Src_mask = 0.0.0.0

Cache Server Name             Admin-status Hash-distribution
squid1                         6          3

HTTP Traffic  From <->; to  Web-Caches

Name: squid1       IP: 172.16.102.66 State: 6 Groups = 1

                     Host->;Web-cache    Web-cache->;Host
         State CurConn TotConn Packets Octets    Packets Octets
Client    active  441    12390 188871    15976623 156962    154750098
Web-Server active  193    11664 150722    151828731  175796    15853612
Total             634    24054 339593    167805354  332758    170603710

某些輸出有些模糊，但通過重複該命令，並且觀察計數器的增長，你能了解攔截是否在進行。

show server real提供幾乎同樣的信息：

ServerIron#show server real squid1

Real Servers Info

Name : squid1                                     Mac-addr: 00c0.4f23.d705

IP:172.16.102.66 Range:1 State:Active       Wt:1    Max-conn:1000000

Src-nat (cfg:op):(off:off) Dest-nat (cfg:op):(off:off)

squid1 is a TRANSPARENT CACHE in groups 1

Remote server : No       Dynamic : No    Server-resets:0

Mem:server: 02009eae Mem:mac: 045a3714

Port State Ms CurConn TotConn Rx-pkts  Tx-pkts  Rx-octet Tx-octet Reas

---- ----- -- ------- ------- -------  -------  -------- -------- ----
http active 0  855    29557 379793 471713 373508204  39425322 0

default active 0  627    28335 425106 366016 38408994 368496301  0

Server  Total    1482 57892 804899 837729 411917198  407921623  0

最後，使用show logging命令來觀察交換機是否顯示squid正常或異常：

ServerIron#show logging
...

00d00h11m51s:N:L4 server 172.16.102.66 squid1 port 80 is up

00d00h11m49s:N:L4 server 172.16.102.66 squid1 port 80 is down

00d00h10m21s:N:L4 server 172.16.102.66 squid1 port 80 is up

00d00h10m21s:N:L4 server 172.16.102.66 squid1 is up

注意ServerIron認為服務運行在80埠。以後你會見到squid運行在3128埠的示例。包過濾規則實際上將包的目的地址從80改變為3128。這導致一些與狀態檢測有關的有趣結果，我在9.3.2.5節里會講到。

9.3.2.3 Extreme Networks

在該示例里，硬體是Summit1i，軟體版本是6.1.3b11。再次將客戶端分配在埠1，Internet在埠2，squid在埠3。網路配置見圖9-5。
<ww-05>;

Extreme交換機僅僅對在不同子網間進行路由的數據包進行HTTP連接的攔截。換句話說，如果你配置Extreme交換機使用二層模式（單一VLAN里），就不能將包轉發給squid。為了讓HTTP攔截正常工作，必須給用戶，Squid，和Internet配置不同的VLAN。

configure Default delete port 1-8

create vlan Users
configure Users ip 172.16.102.1 255.255.255.192
configure Users add port 1

create vlan Internet
configure Internet ip 172.16.102.129 255.255.255.192
configure Internet add port 2

create vlan Squid
configure Squid ip 172.16.102.65 255.255.255.192
configure Squid add port 3

下一步是激活和配置交換機的路由：

enable ipforwarding
configure iproute add default 172.16.102.130

最後，配置交換機重定向HTTP連接到Squid：

create flow-redirect http tcp destination any ip-port 80 source any
configure http add next-hop 172.16.102.66
9.3.2.4 Cisco Arrowpoint

下類配置基於我以前的測試筆記。然而，最近我沒有使用這類型的交換機，不能確保如下命令仍然正確：

circuit VLAN1
  ip address 172.16.102.1 255.255.255.0

service pxy1
  type transparent-cache
  ip address 172.16.102.66
  port 80
  protocol tcp
  active

owner foo
  content bar
add service pxy1
protocol tcp
port 80
active

9.3.2.5 關於HTTP服務和健壯性檢測的評論

在上面的示例里，路由器/交換機都直接轉發包，不會改變目的TCP埠。在9.4章里用到的包過濾規則改變了目的埠。如果試圖在同一主機上運行HTTP服務和squid，那麼就產生了一個有趣的問題。

為了在3128埠運行Squid的同時，還要在80埠運行HTTP，包過濾配置必須有1條特殊的規則，它接受到本機HTTP服務的TCP連接。否則，連接會直接轉交給Squid。該規則易於建立。假如目的埠是80，並且目的地址是伺服器的，那麼主機正常接受這個包。然而所有的攔截包有外部目的地址，所以它們不會匹配該規則。

然而，當路由器/交換機進行HTTP健壯性檢測時，它連接到伺服器的IP地址。這樣，健壯性檢測的數據包匹配了上述規則，它不會轉交給Squid。路由器/交換機檢測了錯誤的服務。假如HTTP服務down掉了，而squid還在運行，那健壯性檢測就產生錯誤結果。

解決這個問題的一些選擇是：
1.不要在Squid主機上運行HTTP服務；
2.增加1條特殊的包過濾規則，將來自路由器/交換機的狀態檢測的包轉交給squid；
3.配置路由器/交換機，改變目的埠為3128；
4.禁止4層狀態檢測。

9.3.3 Cisco策略路由

策略路由與4層交換並非不同。它在Cisco和其他公司的路由產品上執行。主要的區別是策略路由不包括任何健壯性檢測。這樣，假如squid超載或完全不可響應，路由器還會繼續轉發包到squid，而不是將包路由到原始伺服器。策略路由要求squid位於路由器直接相連的子網中。

在本示例里，使用了Cisco 7204路由器，運行IOS Version 12.0(5)T。網路配置與前面的一樣，見圖9-5。
<ww-05>;

首先的配置步驟是定義訪問列表，匹配來自客戶端的到80埠的數據包。必須確保Squid發起的到80埠的數據包不會被再次攔截。做到這點的方法之一是，定義1個特殊規則，拒絕來自squid的數據包，緊跟1條規則允許所有其他的數據包：

access-list 110 deny tcp host 172.16.102.66 any eq www
access-list 110 permit tcp any any eq www

另外，如果Squid和用戶位於不同的子網，你可以僅僅允許來自用戶所在網路的數據包：
access-list 110 permit tcp 10.102.0.0 0.0.255.255 any eq www

下一步是定義路由映射。在這裡你告訴路由器轉發攔截包到何處去：

route-map proxy-redirect permit 10
match ip address 110
set ip next-hop 172.16.102.66

這些命令表明，「假如IP地址匹配訪問列表110，就轉發該包到172.16.102.66」。在route-map行的數字10是一個序列號，假如你有多個路由映射的話。最後一步是應用路由映射到客戶端連接的介面：

interface Ethernet0/0
ip policy route-map proxy-redirect

IOS不對策略路由提供很多調試方法。然而，show route-map命令足夠可用：

router#show route-map proxy-redirect
route-map proxy-redirect, permit, sequence 10

  Match clauses:
ip address (access-lists): 110
  Set clauses:
ip next-hop 172.16.102.66
  Policy routing matches: 730 packets, 64649 bytes

9.3.4 Web Cache Coordination協議

Cisco對4層交換技術的響應叫做Web Cache Coordination Protocol(WCCP).WCCP在許多方面與典型的4層攔截不同。

首先，攔截包被封裝在GRE（路由封裝類）里。這點允許數據包跨子網傳輸，也就意味著squid不必直接連在路由器上。因為數據包是封裝的，squid主機必須對其進行解包。並非所有的Unix系統有解開GRE包的代碼。

第二個不同是，路由器如何決定將負載分攤到多個cache上。事實上，路由器不做這個決定，由cache來做。當路由器有一組支持WCCP的cache時，其中一個cache主動成為組的領導。由領導cache來決定如何分攤負載和通知路由器。在路由器重定向然任何連接之前，這是一個額外的必要步驟。

因為WCCP使用GRE，路由器可能強迫要求將來自HTTP請求的大TCP包分割成片斷。幸運的是，這點不會經常發生，因為大部分HTTP請求比乙太網MTU size（1500位元組）要小。默認的TCP和IP包頭部是20位元組，這意味著乙太網幀能實際攜帶1460位元組的數據。GRE封裝在GRE頭部增加了20位元組，另外在第二個IP頭部增加了20位元組。這樣來自客戶端的正常的1500位元組的TCP/IP包，在封裝后變成了1540位元組。這樣數據包就太大而不能在單個乙太網幀里傳輸，所以路由器將原始包分割成兩個片斷。

9.3.4.1 WCCPv1

該節的配置示例在運行IOS Version 12.0(5)T的Cisco 7204路由器上測試。網路配置跟圖9-5同。

首先，在IOS配置中輸入如下兩行，激活路由器的WCCP:

ip wccp version 1
ip wccp web-cache

接著，必須在單獨的路由器介面上激活WCCP。在HTTP包離開路由器的介面上激活WCCP，也就是路由器連接到外部原始伺服器或Internet網關的介面：

interface Ethernet0/1
ip address 172.16.102.129 255.255.255.192
ip wccp web-cache redirect out

請確認保存了配置改變。

你也許想使用訪問列表來阻止某些web站點的攔截。可以使用訪問列表來防止循環轉發。例如：

! don't re-intercept connections coming from Squid:
access-list 112 deny tcp host 172.16.102.66 any eq www

! don't intercept this broken web site
access-list 112 deny tcp any 192.16.8.7 255.255.255.255 eq www

! allow other HTTP traffic
access-list 110 permit tcp any any eq www

ip wccp web-cache redirect-list 112

路由器不發送任何數據到squid，直到squid宣稱它自己是路由器。我在9.5.1節里解釋如何配置squid的WCCP。

9.3.4.2 WCCPv2

當前標準的Squid發布僅支持WCCPv1。然而，可在http://devel.squid-cache.org/找到WCCPv2的補丁。該代碼仍是實驗性的。

注意從路由器發送到Squid的GRE包，包含了額外的4個位元組。WCCPv2在GRE頭部和封裝的IP包之間，插入了一個重定向頭部。也許需要修改內核代碼來計算這個額外的頭部。

9.3.4.3 調試

IOS提供許多命令來監視和調試WCCP。show ip wccp web-cache命令提供一些基本的信息：

router#show ip wccp web-cache

Global WCCP information:
Router information:
      Router Identifier:                172.16.102.129
      Protocol Version:                   1.0
Service Identifier: web-cache
      Number of Cache Engines:          1
      Number of routers:                1
      Total Packets Redirected:          1424
      Redirect access-list:             -none-
      Total Packets Denied Redirect:    0
      Total Packets Unassigned:          0
      Group access-list:                -none-
      Total Messages Denied to Group:    0
      Total Authentication failures:    0

欲了解更多細節，在前敘命令后加一個detail單詞：

router#show ip wccp web-cache detail

WCCP Cache-Engine information:

      IP Address:          172.16.102.66
      Protocol Version:    0.4
      State:                Usable
      Initial Hash Info:    00000000000000000000000000000000
                           00000000000000000000000000000000
      Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
                           FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
      Hash Allotment:       256 (100.00%)
      Packets Redirected: 1424
      Connect Time:       00:17:40

這裡可以看到squid的IP地址和狀態。假如不止一個cache與路由器會話，那麼hash分配信息看起來不同。大多數情況下，每個cache接受到相等的hash值。

注意第二條命令輸出的協議版本值，與第一條命令的不一樣。不幸的是，賦予了版本號太多的意義。show ip wccp web-cache命令看起來報告WCCP協議的主版本號（例如1或2），然而show ip wccp web-cache detail的版本號看起來匹配Squid的wccp_version指令的值。

9.4 操作系統配置

為了讓cache攔截正常工作，必須在操作系統中激活某些網路功能。首先，必須激活IP包轉發。這就允許操作系統接受目的地址是外部IP的數據包。接著，必須激活和配置內核中的相關代碼，以重定向外部包到Squid。

9.4.1 Linux

本節的指導適合2.4系列Linux內核。我使用RedHat Linux7.2（內核是2.4.7-10）。假如你使用的版本不同，那可能不能運行。建議搜索下Squid的FAQ或其他地方，找到關於內核的更新的或歷史的信息。

在我測試iptables過程中，不必激活IP轉發。然而，你也可以試試在一開始就激活它，並在一切運行良好后，看看能否禁掉它。激活包轉發的最好的方法是在/etc/sysctl.conf文件里增加如下行：

net.ipv4.ip_forward = 1

一般來說，在HTTP攔截生效前，不必編譯新內核。假如你不知道如何配置和創建新Linux內核，請參閱O'Reilly's Running Linux by Matt Welsh, Matthias Kalle Dalheimer, and Lar Kaufman。當你配置內核時，請確認如下選項被激活：

o  General setup
   Networking support (CONFIG_NET=y)
   Sysctl support (CONFIG_SYSCTL=y)

o  Networking options
   Network packet filtering (CONFIG_NETFILTER=y)
   TCP/IP networking (CONFIG_INET=y)
   Netfilter Configuration
   Connection tracking (CONFIG_IP_NF_CONNTRACK=y)
   IP tables support (CONFIG_IP_NF_IPTABLES=y)
   Full NAT (CONFIG_IP_NF_NAT=y)
   REDIRECT target support (CONFIG_IP_NF_TARGET_REDIRECT=y)

o  File systems
   /proc filesystem support (CONFIG_PROC_FS=y)

另外，請確認該選項沒被激活：

o Networking options

Fast switching (CONFIG_NET_FASTROUTE=n)

重定向外部數據包到squid的代碼是Netfilter軟體的一部分。如下是發送HTTP攔截連接到squid的規則：

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Linux內核維護許多不同的tables。-t nat選項表明我們正在修改NAT（網路地址轉換）表。本質上，我們使用iptables將原始伺服器的TCP/IP地址轉換為squid的本地TCP/IP地址。

每個iptables表有許多鏈。-A PREROUTING表明我們增加了一條規則到內建的鏈叫做PREROUTING。PREROUTING鏈僅對從外部網路進入系統的數據包有效。

接下來的三個選項決定哪個包匹配該規則。-i eth0選項限制規則僅對eth0介面上接受的數據包有效。-p tcp選項指定TCP包，--dport 80指定包的目的埠是80。假如這三個條件都是true，那麼包匹配該規則。

-j REDIRECT選項表明對匹配規則的包，採取何種動作。REDIRECT是內建的動作名，它導致iptables改變包的目的地址為127.0.0.1。--to-port 3128選項也指示iptables改變目的TCP埠為3128。

假如你在squid主機上運行HTTP服務（例如Apache），就必須增加另外的iptables規則。該必要規則允許連接到HTTP服務。否則，REDIRECT規則導致iptables轉發連接到squid的3128埠。可以使用-I選項在列表頂部插入一條新規則：

iptables -t nat -I PREROUTING -i eth0 -p tcp -d 172.16.102.66 --dport 80 -j ACCEPT

一旦確認所有iptables規則工作正確，記得運行如下命令來保存配置：

/sbin/service iptables save

將當前規則保存到/etc/sysconfig/iptables，當系統重啟時，這些規則自動載入。

9.4.1.1 Linux和WCCP

2.4版本的Linux內核自帶1個GRE偽裝介面。然而，它不能解碼WCCP任務里封裝的GRE包。問題看起來在於路由器設置了WCCP/GRE包的協議類型域為0x883E。Linux的GRE驅動不知道如何處理這類型包，因為它不了解0x883E類型的協議。

可以試試給Linux打GRE模塊的補丁，以便它能在WCCP下工作。Squid FAQ包含了對這個補丁的鏈接。然而，假如使用WCCP指定的Linux模塊，事情會容易些。可以在這裡找到它：http://www.squid-cache.org/WCCP-support/Linux/ip_wccp.c

必須編譯ip_wccp.c文件為可裝載內核模塊。有點棘手的是，依賴於內核版本的不同，編譯選項可能不同。你可以進入內核源代碼目錄，敲入make modules並觀察編譯器命令的滾動。然後拷貝這些命令中的一個，然後改變最後一個參數為ip_wccp.c。如下是我在2.4.7-10 Linux內核中使用的命令:

% gcc -Wall -D_ _KERNEL_ _ -I/usr/src/linux-2.4.7-10/include  \
  -DMODULE -DMODVERSIONS -DEXPORT_SYMBAB \
  -include /usr/src/linux-2.4.7-10/include/linux/modversions.h \
  -O2 -c ip_wccp.c

gcc命令在當前目錄會生成ip_wccp.o文件。下一步使用insmod命令，裝載模塊到內核中：

# insmod ip_wccp.o

注意ip_wccp模塊接受來自任何源地址的GRE/WCCP包。換句話說，惡意用戶可能發送數據到squid cache。假如使用該模塊，應該安裝一條iptables規則，拒絕外部的GRE包。例如：

# iptables -A INPUT -p gre -s 172.16.102.65 -j ACCEPT
# iptables -A INPUT -p gre -j DROP

不要忘記敲入/sbin/service iptables save命令來保存配置。

9.4.2 FreeBSD

本節的例子基於FreeBSD-4.8,並可以在任何FreeBSD-4和5系列的後續版本上運行。

要激活IP包轉發，在/etc/sysctl.conf中增加如下行：

net.inet.ip.forwarding=1

需要在內核中激活2個特殊選項。假如你不知道如何編譯內核，參見FreeBSD Handbook第9章(http://www.freebsd.org/handbook/index.html). 編輯內核配置文件，確保有如下行：

options       IPFIREWALL
options       IPFIREWALL_FORWARD

假如squid主機位於無人照看的機房中，我也推薦使用IPFIREWALL_DEFAULT_TO_ACCEPT選項。假如你被防火牆的規則困擾，仍然可以登陸系統中。

ipfw命令告訴內核重定向攔截連接到squid:

/sbin/ipfw add allow tcp from 172.16.102.66 to any out
/sbin/ipfw add allow tcp from any 80 to any out
/sbin/ipfw add fwd 127.0.0.1,3128 tcp from any to any 80 in
/sbin/ipfw add allow tcp from any 80 to 172.16.102.66 in

第一條規則匹配squid主機發起的數據包。它確保外出的TCP連接不會被重新定向回squid。第二條規則匹配squid響應客戶端的數據包。我在這裡列出它，因為隨後會有另外的ipfw規則，這些規則會拒絕這些包。第三條規則實際重定向進來的連接到squid。第四條規則匹配從原始伺服器返回squid的數據包。這裡又一次假設隨後會有相應的拒絕規則。

假如在squid主機上運行HTTP服務，就必須增加另外的規則，它放過，而不是重定向，目的地址是原始伺服器的TCP包。下列規則在fwd規則之前：

/sbin/ipfw add allow tcp from any to 172.16.102.66 80 in

FreeBSD典型的將ipfw規則存儲在/etc/rc.firewall里。一旦你確認規則設置正確，記得保存它們。將如下行加入/etc/rc.local文件，讓FreeBSD在啟動時自動運行/etc/rc.firewall腳本。

firewall_enable="YES"

9.4.2.1 FreeBSD和WCCP

FreeBSD版本4.8和後續版本內建了對GRE和WCCP的支持。早期的版本需要補丁，你可以在這裡找到: http://www.squid-cache.org/WCCP-support/FreeBSD/ . 內建代碼的性能非常好，它是真正的內核組織編寫的。可能也需要編譯支持GRE的新內核。將如下行加入內核配置文件里：

pseudo-device gre

對Freebsd-5，使用device代替了pseudo-device。當然，你也需要前面章節里提到的FIREWALL選項。

在安裝和重啟了新內核后，必須配置GRE通道來接受來自路由器的GRE包。例如：

# ifconfig gre0 create
# ifconfig gre0 172.16.102.66 172.16.102.65 netmask 255.255.255.255 up
# ifconfig gre0 tunnel 172.16.102.66 172.16.102.65
# route delete 172.16.102.65

ifconfig命令在gre0介面上，增加了一個到路由器（172.16.102.65）的路由表入口。我發現必須刪除該路由，以便squid能與其他路由器會話。

你也許想或必須對來自路由器的GRE包，增加一條ipfw規則：

/sbin/ipfw add allow gre from 172.16.102.65 to 172.16.102.66

9.4.3 OpenBSD

本節的示例基於OpenBSD 3.3

為了激活包轉發，在/etc/sysctl.conf文件里增加該行：

net.inet.ip.forwarding=1

現在，在/etc/pf.conf文件里增加如下類似行，配置包過濾規則：

rdr inet proto tcp from any to any port = www ->; 127.0.0.1 port 3128
pass out proto tcp from 172.16.102.66 to any
pass out proto tcp from any port = 80 to any
pass in proto tcp from any port = 80 to 172.16.102.66

假如你沒有使用OpenBSD的包過濾器，需要在/etc/rc.conf.local文件里增加一行來激活它：

pf=YES
9.4.3.1 OpenBSD和WCCP
首先，增加如下行到/etc/sysctl.conf文件，告訴系統接受和處理GRE和WCCP包：

net.inet.gre.allow=1
net.inet.gre.wccp=1

然後，用如下命令配置GRE介面：

# ifconfig gre0 172.16.102.66 172.16.102.65 netmask 255.255.255.255 up
# ifconfig gre0 tunnel 172.16.102.66 172.16.102.65
# route delete 172.16.102.65

跟Freebsd一樣，我發現必須刪除ifconfig自動產生的路由。最後，依賴於包過濾器的配置，必須增加一條規則以允許GRE包：

pass in proto gre from 172.16.102.65 to 172.16.102.66

9.4.4 在NetBSD和其他系統上的IPFilter

本節的示例基於NetBSD 1.6.1。它們也能運行在Solaris,HP-UX,IRIX,和Tru64上，既然這些系統本身就配備了IPFilter.

激活NetBSD的包轉發，將如下行加進/etc/sysctl.conf:
net.inet.ip.forwarding=1

然後，將如下行插入NAT配置文件/etc/ipnat.conf中：
rdr fxp0 0/0 port 80 ->; 172.16.102.66 port 3128 tcp

你的介面名可能與本例的fxp0不同。

9.4.4.1 NetBSD和WCCP

我不能在NetBSD上運行WCCP，即使打了GRE補丁來接受WCCP包。該問題看起來根源在IPFilter rdr規則阻塞了特定的埠。來自路由器的包通過NetBSD的gre0介面（在這裡它們被解包）。然而，包回到路由器時，走另一條通道，未被封裝並且不走同一網路介面。這樣，IPFilter代碼沒有將squid的本地IP地址轉換回原始伺服器的地址。
9.5 配置Squid
假如你使用Linux 2.4和iptables，在運行./configure時，可使用--enable-linux-netfilter選項。它激活某些Linux的特殊代碼，以發現發起請求的原始伺服器的IP地址。Squid正常情況下從Host頭部，得到原始伺服器的名字（和/或地址）。--enable-linux-netfilter功能僅對沒有Host頭部的請求來說是必要的。統計顯示幾乎所有的請求有Host頭部，所以實際中可以不使用--enable-linux-netfilter選項。

假如正在使用IPFilter包（NetBSD,Solaris,或其他），因為同樣的理由，你應該使用--enable-ipf-transparent選項。在OpenBSD上，請使用--enable-pf-transparent選項。每次運行./configure時，必須重編譯squid,見3.8章的描述。

在運行了./configure和重編譯了squid后，可以編輯squid.conf文件。作為起點，請確認下列指令定義了給定的值：

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_uses_host_header on
httpd_accel_with_proxy on
httpd_accel_single_host off

http_accel_host指令是關鍵。它指示squid接受包含局部URI的HTTP請求。httpd_accel_uses_host_header被激活，允許squid使用Host頭部來重新構建完整URI。virtual關鍵字指示squid在缺乏Host頭部時，將原始伺服器的IP地址放進URL里。

httpd_accel_with_proxy指令控制squid是否既接受HTTP服務（部分URI）請求，又接受代理（完整URI）請求。在cache攔截里，它應該被激活。如果沒有用戶明確的配置使用squid做代理，那即使httpd_accel_with_proxy沒被激活，squid也能工作。

httpd_acces_single_host指令正常情況下被禁止，在早期版本的squid里，它可能被默認激活。在cache攔截里，它應明確被禁止。

假如攔截不止針對80埠，你也許該將httpd_accel_port設為0。見附錄A的更多信息。

假如你沒有使用WCCP，就該準備開始發起攔截會話到squid了。通過使用瀏覽器來上網衝浪，或者使用squidclient發起測試請求，就可以放手一試。假如你使用WCCP，那麼還有許多步驟要完成。

9.5.1 配置WCCPv1

路由器不發送任何會話到squid，直到squid宣稱它自己是路由器。為了讓squid那樣做，在squid.conf中增加如下行：

wccp_router 172.16.102.65
wccp_version 4

路由器有多個介面。請確認使用與squid相連的介面的IP地址。這點是必要的，因為來自路由器的WCCP消息，將源IP地址設置為外出介面的地址。假如源地址不匹配wccp_router值，squid會拒絕WCCP消息。

WCCPv1文檔規定4作為協議版本號。然而，某些用戶報告，Cisco IOS 11.2僅支持協議版本3。假如你使用該版本的IOS，請在squid.conf里改變版本號：

wccp_version 3

9.6 調試問題

HTTP攔截比較複雜，因為許多不同設備必須組合正確工作。為了幫助你跟蹤問題，如下是一個問題解答檢查列表：

 客戶端數據包正在通過路由器/交換機嗎？
在簡單網路里，這點顯而易見。你可以trace線纜並觀察指示燈的活動閃爍。然而在大而複雜的網路，數據包可能走不同的路線。假如你的組織夠大，並有網路sniffer設備，就可以觀察線路中web客戶端的請求數據包。低技術的方法是，斷開有問題的線路，並觀察是否影響客戶端的web瀏覽。

 路由器/交換機配置是否正確？
你也許要再次檢查路由器/交換機配置。假如你已配置了某個介面，那能否確保它正確呢？
是否新的配置真正在設備上運行？也許在你保存配置之前，路由器/交換機已重啟了。在改變生效前，你或許需要reboot設備。

 交換機/路由器能與squid主機會話嗎？
能從路由器/交換機上ping通squid嗎？大部分4層攔截配置要求網路設備和squid在同一子網裡。登陸路由器/交換機，確認能ping通squid的IP地址。

 交換機/路由器相信squid在運行嗎？
許多傳輸攔截設備不會發送會話到squid，除非它們知道squid是健壯的。使用調試命令來預覽squid的健壯性狀態。也許會發現三層健壯性檢測（例如ICMP ping）比四層檢測（例如HTTP）更容易，它使網路設備更容易將squid標記為存活狀態。

 Squid實際在運行嗎?
請再次確認squid真正在運行，特別是在系統近期重啟過的情況下。

 數據包正在抵達squid主機嗎？
使用tcpdump能見到攔截的TCP連接。如下是示例：
# tcpdump -n -i eth0 port 80

假如使用WCCP，請檢查來自路由器的GRE包：
# tcpdump -n -i eth0 ip proto gre

假如沒有看到tcpdump的任何輸出，則路由器/交換機可能沒有發送任何數據。在這種情況下，返回到以前的建議。

注意，假如設備正使用四層健壯性檢測，你可以在tcpdump的輸出里見到這些。健壯性檢測來自路由器/交換機的IP地址，所以它們容易被認出。假如你見到健壯性檢測，但沒有其他數據，那可能意味著路由器/交換機正把squid的響應理解為不健壯。例如，設備可能想見到200(OK)響應，但squid返回一個錯誤，例如401（未授權）或404（未發現）。請對access.log運行tail -f命令。

 激活了IP轉發嗎？
請再次確認squid運行的操作系統配置了IP包轉發。假如沒有，主機可能會丟棄攔截數據包，因為目的IP地址並非本地。

 配置包過濾了嗎？
請確認包過濾器（例如ipfw,iptables,pf等）配置正確。當每件事都運行良好時，你能定期運行命令來顯示過濾規則，並觀察計數器增長。例如：

# ipfw show 300 ; sleep 3; ipfw show 300
00300  86216 8480458 fwd 127.0.0.1,3128 tcp from any to any 80 in
00300  86241 8482240 fwd 127.0.0.1,3128 tcp from any to any 80 in

注意該示例在FreeBSD上，包和位元組計數器（第二和第三列）正在增長。

 環路介面起來和配置了嗎？
假如有一條規則轉發/重定向包到127.0.0.1，請確認環路介面（例如lo0,lo等）起來了，並配置過它。假如沒有，內核簡單的跳過這條轉發/重定向規則。

 WCCP/GRE包被正確解開了嗎？
假如使用WCCP，請確認GRE包被正確解開。假如因為某些理由，系統不知道該如何處理GRE包，那就在netstat -s的輸出里會見到"unknown/unsupported protocol"計數器在增長。

# netstat -s | grep unknown

      46 packets for unknown/unsupported protocol

假如OS有GRE介面，請頻繁運行netstat -i命令，觀察不斷增長的包數量：

# netstat -in | grep ^gre0

Name Mtu Network    Address             Ipkts Ierrs Opkts Oerrs  Coll
gre0 1476 <Link#4>;
304452    0       0    4    0

另外，在GRE介面上運行tcpdump：
# tcpdump -n -i gre0

 Squid能響應客戶端嗎？
有可能路由器/交換機能發送包到squid，但squid不能將包發送回客戶端。這種情況可能發生在：防火牆過濾規則拒絕外出數據包，或squid沒有到客戶端IP地址的路由。為了檢查這種情況，請運行netstat -n並觀察SYN_RCVD狀態的sockets:

% netstat -n

Active Internet connections

Proto Recv-Q Send-Q  Local Address       Foreign Address       (state)

tcp4    0    0  10.102.129.246.80    10.102.0.1.36260    SYN_RCVD
tcp4    0    0  10.102.129.226.80    10.102.0.1.36259    SYN_RCVD
tcp4    0    0  10.102.128.147.80    10.102.0.1.36258    SYN_RCVD
tcp4    0    0  10.102.129.26.80    10.102.0.2.36257    SYN_RCVD
tcp4    0    0  10.102.129.29.80    10.102.0.2.36255    SYN_RCVD
tcp4    0    0  10.102.129.226.80    10.102.0.1.36254    SYN_RCVD
tcp4    0    0  10.102.128.117.80    10.102.0.1.36253    SYN_RCVD
tcp4    0    0  10.102.128.149.80    10.102.0.1.36252    SYN_RCVD

假如你看到這些，請使用ping和traceroute來確認squid能與客戶端雙向通信。

 Squid能與原始伺服器會話嗎？
假如squid不能連接到原始伺服器，攔截HTTP連接會無法進行。如果這點發生，netstat會顯示許多連接在SYN_SENT狀態：

% netstat -n

Active Internet connections

Proto Recv-Q Send-Q  Local Address       Foreign Address       (state)

tcp4    0    0  172.16.102.66.5217    10.102.129.145.80    SYN_SENT
tcp4    0    0  172.16.102.66.5216    10.102.129.224.80    SYN_SENT
tcp4    0    0  172.16.102.66.5215    10.102.128.71.80    SYN_SENT
tcp4    0    0  172.16.102.66.5214    10.102.129.209.80    SYN_SENT
tcp4    0    0  172.16.102.66.5213    10.102.129.62.80    SYN_SENT
tcp4    0    0  172.16.102.66.5212    10.102.129.160.80    SYN_SENT
tcp4    0    0  172.16.102.66.5211    10.102.128.129.80    SYN_SENT
tcp4    0    0  172.16.102.66.5210    10.102.129.44.80    SYN_SENT
tcp4    0    0  172.16.102.66.5209    10.102.128.73.80    SYN_SENT
tcp4    0    0  172.16.102.66.5208    10.102.128.43.80    SYN_SENT

再次用ping和traceroute來確認squid能與原始伺服器會話。

 外出連接正被攔截嗎？
假如squid能ping通原始伺服器，並且仍然見到大量的連接在SYN_SENT狀態，那麼路由器/交換機可能正在攔截squid的外出TCP連接。在某些情況下，squid能檢測到這種轉發循環，並寫警告日誌到cache.log。如此的轉發死循環能迅速耗光squid的所有文件描述符，這樣也會在cache.log里產生警告。

假如你懷疑這個問題，請使用squidclient程序來發起一些簡單的HTTP請求。例如，該命令發起一條直接到原始伺服器的HTTP請求：
% /usr/local/squid/bin/squidclient -p 80 -h slashdot.org /

假如該命令成功，你可以在屏幕上見到來自Slashdot站點的許多難看的HTML。然後通過squid來試試同樣的請求：
% /usr/local/squid/bin/squidclient -r -p 3128 -h 127.0.0.1 http://slashdot.org/

假如沒有在cache.log里看到錯誤消息，就可以再次在屏幕上看到一些HTML。假如看到轉發循環錯誤，就必須重新配置交換機/路由器，以便它允許squid的外出連接正常通過，而不被攔截。

《解決方案》