[好文共享]《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的外出連接正常通過,而不被攔截。
《解決方案》

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

hao
《解決方案》

終於把她拷完了,好長,謝謝了
《解決方案》

好東西.收藏
《解決方案》

好東東,謝謝!!
《解決方案》

還有其他章節的翻譯嗎?

《解決方案》

終於找到我需要的東西了,知道如何用Cisco的交換機與路由器重定向80埠了。
《解決方案》

還有嗎???????????????????
《解決方案》

一整晚上都在看這幾章,,真的些的很不錯 。。翻譯就更是不用說了哦 。。
《解決方案》

正如文章標題,本文確是權威作品,值得一讀。




[火星人 ] [好文共享]《Squid 中文權威指南》第9章 譯者:彭勇華已經有545次圍觀

http://coctec.com/docs/service/show-post-16756.html