最近更新日期:2011/04/08
17.1 什麼是代理伺服器 (Proxy)
17.1.1 什麼是代理伺服器 17.1.2 代理伺服器的運作流程 17.1.3 上層代理伺服器 17.1.4 代理伺服器與 NAT 伺服器的差異 17.1.5 架設代理伺服器的用途與優缺點 17.2 Proxy 伺服器的基礎設定 17.2.1 Proxy 所需的 squid 軟體及其軟體結構 17.2.2 CentOS 預設的 squid 設定: http_port, cache_dir (SELinux), cache_mem 17.2.3 管控信任來源 (如區網) 與目標 (如惡意網站): acl 與 http_access 的使用 17.2.4 其他額外的功能項目 17.2.5 安全性設定:防火牆, SELinux 與黑名單檔案 17.3 用戶端的使用與測試 17.3.1 瀏覽器的設定: firefox & IE 17.3.2 測試 proxy 失敗的畫面 17.4 伺服器的其他應用設定 17.4.1 上層 Proxy 與獲取資料分流的設定 17.4.2 Proxy 服務放在 NAT 伺服器上:通透式代理 (Transparent Proxy) 17.4.3 Proxy 的認證設定 17.4.4 末端登錄檔分析: sarg 17.5 重點回顧 17.6 本章習題 17.7 參考資料與延伸閱讀 17.8 針對本文的建議:http://phorum.vbird.org/viewtopic.php?f=16&t=35439 17.1 什麼是代理伺服器 (Proxy) 代理伺服器 (Proxy) 的原理其實很簡單啦!就是以類似代理人的身份去取得使用者所需要的資料就是了!
但是由於它的『代理』能力,使得我們可以透過代理伺服器來達成防火牆功能與用戶瀏覽資料的分析!
此外,也可以藉由代理伺服器來達成節省頻寬的目的,以及加快內部網路對網際網路的 WWW 存取速度!總之,
代理伺服器對於企業來說,實在是一個很不錯的東西啊! 17.1.1 什麼是代理伺服器 在真實世界中,我們或許會幫忙家人去辦理一些雜務吧!舉個例子來說,例如繳費或者是申辦提款卡等等的, 由於你並不是『申請者本人』而是『代理人』的角色,因此有時候會需要秀出一些證件就是了。 那麼在網路上面的代理伺服器 (Proxy Server) 是怎麼回事呢?它最主要的功能就如同我們上面提的真實世界一樣, 當用戶端有網際網路的資料要求時,Proxy 會幫用戶去向目的地取得用戶所需要的資料。 所以,當用戶端指定 WWW 的代理伺服器之後,用戶的所有 WWW 相關要求就會通過代理伺服器去捉取囉! 整個代理伺服器與用戶端的相關性可以由下圖約略看出一個端倪: 圖 17.1-1、代理伺服器、用戶端與網際網路的相關性示意圖 一般來說,代理伺服器會架設在整個區網的單點對外防火牆上頭,而在區網內部的電腦就都是透過 Proxy 來向網際網路要求資料的,這就是所謂的『代理伺服器』啦!當然,上面的架構僅只是一個案例,但是這個架構比較多人用的原因, 是因為這樣的 Proxy server 還可以兼做高階防火牆之用啦! 在 Proxy 與用戶端的相關性當中,你必需要瞭解的是:用戶端向外部要求的資料事實上都是 Proxy 幫用戶取得的,因此網際網路上面看到要求資料者,將會是 Proxy 伺服器的 IP 而不是用戶端的 IP。 舉個例子來說,假如鳥哥在我的瀏覽器設定了我們學校的代理伺服器主機 proxy.ksu.edu.tw 做為我的 Proxy 好了,再假設我的 IP 是 120.114.141.51 ,那麼當我想要取得 Yahoo 的新聞資訊時,事實上,都是 proxy.ksu.edu.tw 幫我去取得的,所以在 Yahoo 的網站上面看到要求資料的人是誰呢?呵呵!當然就是 proxy.ksu.edu.tw 而不是 120.114.141.51 囉!這樣可以瞭解 Proxy 的功能了嗎? 除了這個功能之外,Proxy 還有一個很棒的額外功能,那就是防火牆的功能! 看一下上面的圖示,你可以發現一件事情,那就是用戶端的個人電腦要連上網際網路一定要經過 Proxy 伺服器。並且,如果有人想要入侵你的系統時,由於你的 proxy 在最外部啊,所以攻擊者就會攻擊錯方向,如此一來,不就比較安全! 此外,由於整個網際網路對外都是經過 proxy ,也就是『單點對外』的情況,這種狀態底下要來管理防火牆也是比較簡單的喔!^_^ 17.1.2 代理伺服器的運作流程 瞭解了 Proxy 的功能之後,我們來談一談那麼 Proxy 到底是怎樣運作的呢?為何它會有『加快網路存取效率』的好處? 這就必需要以底下的圖示來說明了! 圖 17.1-2、代理伺服器的運作流程圖:快取資料與用戶端 當用戶端指定了代理伺服器之後,在用戶端想要取得網際網路上面的資訊時,它是這樣取得資料的
(註:那個 Cache 表示為 Proxy 主機的硬碟的意思):
上面的流程分析裡面,我們可以清楚的知道,當 Proxy 曾經幫某位用戶取得過 A 資料後,當後來的用戶想要重複取得 A 資料時,那麼 Proxy 就會從自己的快取裡面將 A 資料取出傳送給用戶,而不用跑到網際網路去取得同樣的這份資料喔。因為沒有去網際網路找資料,當步驟 4 的流程很花時間時,那麼透過 Proxy 忽略步驟 4 ,感覺上就好像網路速度變快了!但其實只是直接從 Proxy 的快取裡面抓而已 (所以才會有人說『假象網路加速』的功能)!這就是兩個流程最大的差異了。 在目前的網際網路社會裡,由於寬頻技術已經很成熟,所以在不亂用的情況下,網路頻寬理論上是足夠的 (除非要連到國外去)。 那麼用了 Proxy 之後效能會不會更提升呢?答案是,『應該不會』!啥?怎麼會這樣呢?從上面的流程分析中, 我們發現 Proxy 會常常去讀取硬碟內的資料,而硬碟內的快取資料又是透過某些特殊方式在管理, 因此要找到該份資料就要花一些時間,再加上如果硬體效能 (硬碟或主機板晶片組) 不佳時,那麼加了 Proxy 反而會讓你感覺網路傳輸怎麼『卡卡的』呦!這點得要特別注意才行!
17.1.3 上層代理伺服器 想一想,既然 Proxy 是幫忙用戶端進行網頁代理的工作,那麼我們的 Proxy 能不能也指定另外一台 Proxy 當成我的 Proxy 的 Proxy 呢?很繞口吧!其實流程像底下這樣啦: 圖 17.1-3、上層代理伺服器示意圖 就是我們的 Local proxy 並不會主動的去捉資料,而是再透過『上層代理伺服器』向 Internet 要求資料!這樣有什麼好處呢?由於可做為我們的上層代理伺服器的主機通常是具有較高頻寬的, 因此我們透過它去要求資料當然『理論上』速度會更快喔!而上層代理伺服器最大的好處其實是在於『分流』喔! 例如下圖所示: 圖 17.1-4、以多部上層代理伺服器達到分流的效果示意圖 我總共設定了三部上層代理伺服器,由於這三個代理伺服器對外的速度都不相同,所以,當我要去美國時,就以 Proxy1 來要求資料,要連歐洲就以 Proxy3 ,至於要連日本,就以 Proxy 2 來要求我所需要的資料,如此一來,呵呵!可以讓我的 Proxy 達到最佳的效能喔!很不錯吧!此外,為了節省上層 proxy 的負擔,如果是其他網路位置,我們則設定由自己的 local proxy 捉取∼ 設定的彈性很高呢! 由於代理伺服器需要管控信任的來源端用戶端電腦,因此各 ISP 僅能針對自家的用戶來開放 Proxy 使用權而已。 台灣常見的幾家 ISP 提供的 Proxy 有:
由於當用戶透過 Proxy 連到網際網路時,網路看到的是 Proxy 在抓取資料而不是該用戶端,因此,我們不難發現 Proxy 有可能會被用戶端過度的濫用,同時也有可能會被拿來為非作歹啊!所以,目前絕大部分的 Proxy 已經『停止對外開放』了,僅針對自己的網域內的用戶提供本項服務而已∼ 因此,如果你要自行設定 Proxy 的時候,請記得去你當初申請網路的 ISP (如果是學術單位,請到貴單位的計中網頁瞧瞧即可) 搜尋一下,才能比較有效的設定好你的伺服器喔!因為設定錯誤的話,呵呵!上層 Proxy 根本不提供服務,或者是上層 Proxy 的效能並不好,那個時候你的 Proxy 也會連帶的受到很大的影響啊!慎選!慎選! 17.1.4 代理伺服器與 NAT 伺服器的差異 或許你已經發現了一件事,那就是:在內部區域網路使用私有 IP 的用戶端,不論透過 Proxy 或者 NAT 均可以直接取得 WWW 的服務,那麼 NAT 與 Proxy 有沒有什麼不同的地方啊?它們不都是可以讓內部的電腦連接出去嗎?其實這兩個玩意兒差異性是『相當大』的喔! 簡單說明如下:
這樣說有沒有比較有點概念了呢?NAT 伺服器是由較底層的網路去進行分析的工作,至於通過 NAT 的封包是幹嘛用的, NAT 不去管他!至於 proxy 則主要是由一個 daemon 的功能達成的,所以必需要符合該 daemon 的需求,才能達到某些功能! 17.1.5 架設代理伺服器的用途與優缺點 現在我們約略知道 Proxy 的功能了,那麼通常什麼情況下會架設 Proxy 呢?一般來說,代理伺服器的功能主要有:
由於 Proxy 的這種特性,讓他很常被使用於大型的企業內部,因為可以達到杜絕內部人員上班時使用非 WWW 以外的網路服務,而且還可以監測使用者的資料要求流向與流量呢!很不錯吧! ^_^!好了,接下來我們來談一談當你架設了 Proxy 後的優缺點吧。先來談談主要可能具有的優點有:
由於代理伺服器的這些優點,因此這裡要強烈的建議,如果你需要連上國外的網頁, 請一定使用 ISP 提供給你的代理伺服器來幫忙,因為不但可以節省頻寬,並且速度上會快上很多很多 (例如美國環保署, EPA 網站)。 不過,有利就有弊,當然 Proxy 也不是萬能的天神∼他有什麼可能潛藏的缺點呢?
總之, Proxy 的優點是很多的,但是缺點卻需要網管人員的操心啊!既然如此,那麼我們到底有沒有需要架設代理伺服器呢? 簡單的說,我們可以這樣分析!
如果你有上述的環境狀況,那麼是可以考慮架設 Proxy 的,但是,相反的來說,要是 (1)我的 Client 端很少,所以每次連上 WWW 都是求取新的資料 (並沒有用到快取),有沒有 Proxy 反而看不出效益∼此外,(2)Proxy 由於屬於應用層了,對於 Internet 的規劃上彈性較不足!不像 NAT 伺服器可以進行很多的功能!(3)我常常上的網站是類似討論區那種一日多變的網站, 在這樣的情況下,實在是沒有必要架設 Proxy 的! 但是,如果對於學校單位那原本頻寬就不足的環境中,架設 Proxy 來讓校內的網路速度提昇,呵呵!就是有那個必要性的啦!所以要不要架設 Proxy 呢?請好好的依據你的環境來考量喔!但無論如何,我們還是要教大家怎麼架設它就是了 ^_^ 17.2 Proxy 伺服器的基礎設定 雖然在我們小型的網路環境中,架設 Proxy 真的沒有什麼用,不過,考慮到大家未來可能會高昇嘛!所以企業常用的 Proxy 也需要瞭解一下比較好。
在這個小節中,我們主要介紹一個比較簡單的 Proxy 環境,就是單純可以跑而已的代理伺服器。比較高階的設定請參考後續小節的介紹囉。 17.2.1 Proxy 所需的 squid 軟體及其軟體結構 達成代理伺服器功能的軟體很多,例如效能不是很好的 Apache 以及我們這個章節要介紹的八爪章魚 squid 這一套。 目前代理伺服器在 Unix Like 的環境下,大多就是使用 squid ,因此我們這裡以 squid 為準來介紹啦。同樣的, 請使用 rpm 來檢查,如果尚未安裝,請用『 yum install squid 』來安裝吧!安裝好 squid 之後,它主要的提供的設定檔有:
其他重要的目錄與檔案有:
17.2.2 CentOS 預設的 squid 設定 在預設的情況下,CentOS 的 squid 具有底下幾個特色:
其實, CentOS 預設的 squid 設定,是僅針對本機 (localhost) 開放的情況,而一大堆設定的預設值, 都是僅針對小型網路環境所指定的數值,同時,很多比較特殊的參數都沒有啟動。所以,我們就得要來瞭解一下各設定值的意義, 這樣才能夠進行修改嘛!這些參數都是在 squid.conf 裡頭指定的,所以,就讓我們來看看這個檔案的內容與較重要的參數吧:
光是瞭解上述的一些基礎設定值,可能就要頭昏昏了,更別說 squid.conf 裡面的其他設定值,看到頭好昏...
無論如何,上述這些設定已經是很基礎的設定了,你最好瞭解一下!先不要進行任何修改,讓我們以預設值來直接啟動 squid
看看有什麼特別的地方再說。
要啟動 squid 真是簡單,讓我們來啟動 squid 並且觀察有沒有相關的埠口吧!
squid 預設會啟動 3128 及 3130 兩個埠口,其中要注意的是, 實際幫用戶進行監聽與傳送資料的是 port 3128 (TCP),3130 (UDP) 僅是負責與鄰近 Proxy 互相溝通彼此的快取資料庫的功能,與實際的用戶要求無關。因此,如果你的 proxy 是單純的單一主機,或者是單純的作為防火牆功能,那麼這個 port 3130 是可以關閉的。
事實上,如果你的用戶端與 proxy 之間的溝通想要使用加密機制的 SSL 功能,以保障用戶端的資訊避免被竊取時,
那麼還有個 https_port 可以取代 http_port !不過,充其量我們的 proxy 並非公開也僅是架設在內部區網,
因此還不需要使用到這個 https_port 啦!
從前面的說明我們知道磁碟快取是影響 proxy 效能的一個相當重要的參數,那麼 squid 是如何將快取存進磁碟的呢? squid 是將資料分成一小塊一小塊,然後分別放置到個別的目錄中。由於較多的目錄可以節省在同一個目錄內找好多檔案的時間 (想一想,分門別類的放置書籍在不同的書櫃內,總比將所有書籍雜亂無章的放置到一個大書櫃要好的多吧!), 因此,在預設的 /var/spool/squid/ 目錄下, squid 又會將它分成兩層子目錄來存放相關的快取資料,所以觀察該目錄就會是:
現在我們知道了較多的目錄是為了將資料分門別類放置,但是第一層 16 個與第二層 256 個是怎麼來的? 讓我們來瞧一瞧 cache_dir 這個重要參數的設定是怎樣:
在 /var/spool/squid/ 後面的參數意義是:
根據 squid 的說法與其他文獻的說明,這兩層快取目錄較佳的配置就是 16 256 以及 64 64 這兩種配置, 所以我們也不需要修改相關的資料啦!重點時還得要注意這個目錄的檔案擁有者與 SELinux 類型才成呦!
想一想,既然快取是放在磁碟上面的,那麼快取的資料會不會塞滿整個快取磁碟呢?當然會啊!而且當塞滿磁碟之後, 你的 proxy 恐怕就無法繼續運作了!所以,我們當然得要好好的注意磁碟使用量是否已經飽和了。在上述的例題中, 若 /var/spool/squid 塞滿 500MB 而 /srv/squid 塞滿 2GB 那麼你的 proxy 就掛了。為了避免這個問題,因此 squid 有底下兩個重要設定:
代表當磁碟使用量達 95% 時,比較舊的快取資料將會被刪除,當刪除到剩下磁碟使用量達 90% 時,就停止持續刪除的動作。
以本案例中,總共 2.5GB 的容量,當用到 2.5*0.95=2.375G 時,舊的資料會開始被刪除,刪到剩下 2.5*0.9=2.25GB
時,就停止刪除的意思。所以會被刪除掉 125MB 的舊資料就是了。通常這個設定值已經足夠了,不需要變動他,
除了你的快取太大或太小時,才會調整這個設定值。
事實上,除了磁碟容量之外,記憶體可能是另一個相當重要的影響 proxy 效能的因子!怎麼說呢?因為 proxy 會將資料存一份在磁碟快取中,但是同時也會將資料暫存在記憶體當中啊,以加快未來使用者存取同一份資料的速度! 但是這個記憶體快取是需要花費額外的伺服器實體記憶體的量,所以就得要以額外的設定值來指定囉。那就是 cache_mem 這個設定值的功能了。 很多人 (包括鳥哥) 都會誤會 cache_mem 的用途!其實 cache_mem 是額外的指定一些記憶體來進行比較『熱門』的資料存取! cache_mem 並不是指我要使用多少記憶體給 squid 使用,而是指 "我還要額外提供多少記憶體給 squid 使用" 的意思』!由於預設 1GB 的磁碟快取會佔用約 10M 的記憶體,而 squid 本身也會佔用約 15MB 的記憶體, 因此,上個例題中 squid 使用掉的記憶體就有:
squid 官方網站建議你的實體記憶體最好是上面數值的兩倍,也就是說,上述的記憶體使用量已經是 48MB, 則我的實體記憶體最好至少要有 100 MB 以上,才會有比較好的效能!當然,這個單指 Proxy 部分而已,如果你的該部主機還有負責其他的工作,呵呵!那麼記憶體就得在累加上去啦!一般來說,如果你的 Proxy 很多人使用時,這個值越大越好,但是最好也要符合上面的需求喔!
17.2.3 管控信任來源 (如區網) 與目標 (如惡意網站): acl 與 http_access 的使用 在上面的基礎設定中,其實僅有 proxy 伺服器本身可以向自己的 proxy 要求網頁代理∼那有個屁用啊? 我們的重點是想要開放給區網來使用這個 proxy 的嘛!所以當然得要修改信任用戶的管控參數囉。 此時,那個重要到不行的 acl 就得要來瞧一瞧啦!這個 acl 的基本語法為:
由於 squid 並不會直接使用 IP 或網域來管控信任目標,而是透過 acl 名稱來管理,這個 <acl 名稱>
就必須要設定管理的是來源還是目標 (acl 類型) ,以及實際的 IP 或網域 (設定的內容) 啦!這個 acl
名稱可以想成是一個暱稱就是了。那麼有哪些重要的 acl 類型呢?基本上有這些:
由於網際網路主要有使用 IP 或主機名稱來作為連線方式的,因此信任用戶的來源至少就有底下幾種:
除了管理來源用戶之外,我們還能夠管理是否讓 proxy 伺服器到某些目標去獲取資料喔!在預設的設定中, 我們的 proxy 僅管理可以向外取得 port 21, 80, 440... 等埠口的目標網站,不是這些埠口就無法幫忙代理取得。 至於 IP 或網域則沒有管理。基本的管理有這些方式:
除了上述的功能之外,我們還能夠使用外部的檔案來提供相對應的 acl 內容設定值喔! 舉例來說,假設我們想要抵擋的外部主機名稱常常會變動,那麼我們可以使用 /etc/squid/dropdomain.txt 來設定主機名稱, 然後透過底下的方式來處理 acl dropdomain dstdomain "/etc/squid/dropdomain.txt" 然後在 dropdomain.txt 當中,一行一個待管理的主機名稱,這樣也能夠減少持續修改 squid.conf 的困擾!
好了!瞭解了 acl 之後,接下來得要談談 http_access 這個實際放行或拒絕的參數了!
設定好 acl 之後,接下來就是要看看到底要不要放行喔∼放行與否跟 http_access 這個項目有關。基本上, http_access 就是拒絕 (deny) 與允許 (allow) 兩個控制項目,然後再加上 acl 名稱就能夠達到這樣的功能了! 只是你得要特別注意的是:http_access 後面接的資料,是有順序的!這個觀念很重要喔! 我們用底下的案例來說明好了: 假設我要放行內部網路 192.168.1.0/24, 192.168.100.0/24 這兩段網域,然後拒絕對外的色情相關圖片, 以及 facebook.com 網站,那麼就應該要這樣做:
你得要注意,如果先放行了 vbirdlan 才抵擋 dropdomain 時,你的設定可能會失敗!因為內網已經先放行, 因此後面的規則不會比對,那麼 facebook.com 就無法被抵擋了!這點得要很注意才行! 通常的作法是,先將要拒絕的寫上去,然後才寫要放行的資料就好了。 17.2.4 其他額外的功能項目
從前面的說明我們知道 Proxy 的快取通常在記錄比較少變動的資料,如果是討論區或者是程式控制類的資料庫型態網頁, 那麼恐怕就沒有快取的需要,因為資料一直變動嘛!你總不希望你發了一帖留言,結果等一下再去瀏覽時,看到的還是舊留言吧! 所以囉,在預設的情況下,squid 已經拒絕某些資料的快取了,那就是底下的幾個設定值:
我們知道通常 .php 結尾的網頁大部分就是討論區之類的變動性資料,那麼能不能出現 .php 結尾的網頁就不要快取呢? 當然可以啊!那該如何進行?我們以上面的資料來照樣造句一下吧!
還記得底下的設定值嗎?這個設定值的參數是這樣設定的:
如果你的伺服器主機名稱尚未決定,因此使用的主機名稱在網際網路上面是找不到對應的 IP 的 (因為 DNS 未設定), 那麼在預設的 squid 設定中,恐怕會無法順利的啟動。此時你可以手動的加入一個主機名稱,就是透過 visible_hostname 來指定。 同時,如果用戶端使用 squid 出現任何錯誤時,螢幕上都會出現管理員的 email 讓用戶可以回報。現在假設主機名稱為 www.centos.vbird 且管理員的 email 為 dmtsai@www.centos.vbird ,此時我們可以這樣修改:
17.2.5 安全性設定:防火牆, SELinux 與黑名單檔案
現在我們已經設定了讓 192.168.100.0/24 及 192.168.1.0/24 這兩段來源使用我們的 proxy server , 那麼想當然爾,防火牆的設定就得要開放這兩段使用 port 3128 才行啊!不過你得要特別注意,並不是開放防火牆就能使用 proxy server 的資源,還得要使用 acl 配合 http_access 才行呦!注意注意!假設你已經使用了 iptables.rule , 那麼修改的方法就是這樣:
針對 proxy 來說,CentOS 5.x 倒是沒有給予太多的規則限制,因此似乎不太需要修訂規則。不過,SELinux
的安全本文在類型部分得注意。這包括設定檔 (/etc/squid/ 內的資料) 類型得是 squid_conf_t 的樣式,
而快取目錄的類型則是 squid_cache_t 的類型,且上層類型 (/var/spool/) 應該是要成為 var_t 之類的才行。
修改的方法就是透過 chcon 來處理即可。
我們在 17.2.3 小節裡面談到,可以透過『 dstdomain .domain.name 』來抵擋不想連線的網站。 不過每次都得使用 root 身份來設定 squid.conf 才行。那有沒有辦法額外處理出一個檔案,讓想要拒絕連線的資料寫入, 這樣比較容易管理,不需要一直去修改 squid.conf 嘛!有沒有辦法可以達成呢?有的,就透過特定檔案來處置即可。 看看底下這個例題來修訂一下吧:
這個方法的好處是,你可以使用額外的控制方式去修改 /etc/squid/dropdomain.txt 這個檔案的內容, 並且修改完畢後再使用 reload 去載入設定檔,不必要重新啟動 (restart),因為 reload 的速度比較快速。 舉例來說,鳥哥的專題生就用 PHP 寫了一支控制該檔案的網頁介面,可以讓老師在上課時直接透過網頁輸入要被控制的目標網站, 這樣學生就無法在上課時連線到外面的某些網站去玩遊戲囉∼ 17.3 用戶端的使用與測試 既然 proxy 是給瀏覽器用的,那麼自然在瀏覽器上面就需要設定一些參數囉!那麼如何設定呢?由於不同的瀏覽器在設定
Proxy 的地方也都不同,所以底下我們介紹目前比較常見的兩款瀏覽器,分別是 firefox 以及 IE
的設定,至於其他的瀏覽器,請參考各瀏覽器的相關說明啊! 17.3.1 瀏覽器的設定: firefox & IE
要在 firefox 4.X 上面設定好 proxy 基本步驟是這樣的:首先打開 firefox 軟體,出現如下的圖示後,點選:『工具』內的『選項』, 示意畫面如下所示: 圖 17.3-1、在 firefox 上頭設定 proxy 的流程 然後在出現的如下畫面中,先選擇右上方的『進階』項目,然後點選『網路』頁面,最後再點選連線的『設定』按鈕, 如下圖所示,依序來動作: 圖 17.3-2、在 firefox 上頭設定 proxy 的流程 此時就會出現如下圖所示的要你輸入代理伺服器的相關資料。請先點選『手動設定』之後才能夠填寫底下的方格。 填上我們伺服器的 IP (鳥哥的案例中,使用的是 192.168.1.10 這一部) 以及埠口,然後鳥哥建議你也可以勾選『所有通訊協定都用此 proxy 』的項目,都設定妥當後,才按下確定。如下圖所示的流程: 圖 17.3-3、在 firefox 上頭設定 proxy 的流程 這樣就設定好 firefox 的 proxy 相關資料了,有夠簡單吧!
那麼 IE 要怎麼設定呢?也是很簡單啦!首先,打開 IE 軟體,你會看到如下的示意圖,點選『工具』內的『網際網路選項』, 流程如下所示: 圖 17.3-4、在 IE 上頭設定 proxy 的流程 在接下來的視窗中,點選『連線』的頁面,然後按下『區域網路設定』的按鈕。流程如下所示: 圖 17.3-5、在 IE 上頭設定 proxy 的流程 最後就是要輸入正確的 proxy server 的 IP 與 port 的相關資料啊!如下圖所示,先點選箭頭 1 所指定的項目,然後才能夠開始填寫正確資料。 一般來說,近端網址 (例如區網的伺服器) 可以不透過 proxy 去捉取資料,因此這裡可以勾選箭頭三所示意的方框喔! 這樣就設定完畢。 圖 17.3-6、在 IE 上頭設定 proxy 的流程 接下來讓鳥哥用 firefox 來測試一下,如果你要連的網站是被拒絕的會如何? 17.3.2 測試 proxy 失敗的畫面 開始利用你的瀏覽器來瀏覽各個網站,基本上你都會發現正確的網站內容。但如果你要連的網站是剛剛被拒絕的呢? 舉例來說,剛剛我們有設定拒絕連向 facebook 的喔!那麼如果你真的輸入網址是 www.facebook.com ,那螢幕上應該是會這樣輸出的! 圖 17.3-7、連線被 proxy 拒絕時的反應情況 從上圖我們可以發現,目標網站是 www.facebook.com ,然後產生問題的地方在於『 Access Denied 』,表示問題的發生在於 proxy 的設定,然後系統還很好心的告訴你管理員 (cache administrator) 的 email ,讓你有問題可以回報給他。 最後,這個資訊是否為新的?底下還會告訴你這個錯誤發生的時間點呢!這樣有沒有很清楚啊? ^_^! proxy 的錯誤不只是這些,因此,當你還有發現無法連線的網站時,請務必要看看螢幕的輸出資訊才好呦! 17.4 伺服器的其他應用設定 除了基本的 proxy 設定之外,如果你還有其他可供利用的上層代理伺服器,說不定我們就能夠設計一下如何進行分流的動作了!
此外,如果針對信任用戶來說,難道得要一直使用 acl 直接指定用戶來源然後再用 http_access 放行?有沒有認證功能啊?
這樣就不用一直修改設定啊!這些其它的應用設定在這個小節來談談吧! 17.4.1 上層 Proxy 與獲取資料分流的設定 能夠找到的上層 proxy 伺服器我們在 17.1.3 裡面談過了,你可以重新回去瞧瞧。 不過,假設你所在的環境並沒有上層代理伺服器,但是你有兩部 Linux 主機放置在不同的 ISP 環境下, 這兩個 ISP 對某些國外的頻寬流量不同,所以你想要根據這樣的情況來設計一下獲取 WWW 網頁的分流時,可以怎麼做? 我們舉個例子來說好了:
現在我們規劃 hinet.centos.vbird 是上層代理伺服器,因此這部主機得要開放 www.centos.vbird 這部機器的使用權, 這動作包括: (1)利用 acl srcdomian 等方式放行 www.centos.vbird 的使用權; (2)開放 www.centos.vbird 的 port 3128 的防火牆過濾功能。如此一來,我們這部 www.centos.vbird 才能夠使用上層代理伺服器喔!也就是說,這兩部主機都要是你能夠掌握的才行 (至少也要上層 ISP 能夠替你開放使用權啦)。 那麼 www.centos.vbird 要如何設定呢?基本上,設定上層代理伺服器與分流的參數主要有: cache_peer, cache_peer_domain,
cache_peer_access 等,分別說明語法如下:
這個設定值就是在規範上層代理伺服器在哪裡,以及我們想要對這部代理伺服器如何查詢的相關設定值。
這個設定值的意思是說,你想要使用這部上層代理伺服器向哪個領域名稱要求資料。
與 cache_peer_domain 相當類似,只是 cache_peer_domain 直接規範了主機名稱 (domain name), 而如果你想要設計的並非領域名稱,而是某些特定的 IP 網段時,就得要先用 acl 設計一個名稱後, 再以這個 cache_peer_access 去放行 (allow) 或拒絕 (deny) 讀取了。 根據上述的語法說明,那麼我們想要達到 .cn 使用 hinet.centos.vbird 這部伺服器的代理功能時, 應該要這樣設計的:
如果你還有其它的需求再利用 acl 規範了目標位置後,再以 cache_peer_access 去放行吧! 如此一來,你的 proxy server 就是一部會主動的依據不同的要求向不同的上層伺服器求取資料的聰明 proxy 囉! 17.4.2 Proxy 服務放在 NAT 伺服器上:通透式代理 (Transparent Proxy) 從上面的說法來看,我們可以發現 proxy 可以做到類似防火牆的功能 (acl dst, acl dstdomain 再配合 http_access 處理), 但是,我們也知道瀏覽器得要設定好 proxy 之後,才會真的使用 proxy 嘛!那就不就是在耍寶用的防火牆嗎? 只要你的用戶知道不要設定 proxy 就可以躲過你的管控,那這部 proxy 防火牆有啥屁用啊?您說是吧? 那該如何強制使用者一定要使用你的 proxy 呢?很簡單!那就是: (1)在對外的防火牆伺服器 (NAT) 上面安裝 proxy; (2)在 proxy 上頭啟動 transparent 功能; (3) NAT 伺服器加上一條 port 80 轉 port 3128 的規則,如此一來,所有往 port 80 的封包就會被你的 NAT 轉向 port 3128 , 而你的 port 3128 就是 proxy ,那大家就得要用你的 proxy ,而且重點是,瀏覽器不需要進行任何設定! 呵呵!也就是說,當使用者是經過 NAT 伺服器連線出去時,只要讓 NAT 伺服器發現『咦!你是要去捉 WWW 的資料對吧!好!那麼這個動作由 Proxy 服務幫你搞定!』如此一來,使用者根本就不需要在瀏覽器上面設定 Proxy 的相關資料,因為這個動作是『由 NAT 伺服器自己決定的』,所以只要在 NAT 伺服器上面設定妥當即可,使用者不必設定任何資料呢!呵呵!真是不錯!而且進行的動作非常簡單!
接下來,將來自 192.168.100.0/24 這個內網的來源,只要是要求 port 80 的,就將它重新導向 port 3128 的方式為:
這樣就結束啦!很簡單吧!通常這樣的環境相當適合學校內的教室或者是計中的環境,
因為這樣學校內部根本不需要請學生設定瀏覽器的 proxy 功能,立刻就能夠達到我們所需要的管控能力!很棒吧!
不過,雖然這樣的功能已經很棒了,但是鳥哥實際用在學校教室環境中卻發現了一些問題,
那就是很多同學同時上傳同一個檔案到外部伺服器去,因為 proxy 快取的功能,結果讓學生一直取得舊的檔案,
對於教網頁製作的老師來說,很困擾∼因為教學過程中常常需要上傳最新的網頁嘛!但是 proxy 快取住,
所以卻得到錯誤的資料了∼那怎辦?
既然我們這個 transparent proxy 的目的僅是在進行控管,並不要去處理快取的任務 (因為頻寬假設是夠的), 那麼乾脆就不要快取啦!這樣不就 OK 啦?好吧!那我們就來搭配 transparent 進行這個設定看看。 假設 transparent proxy 已經設定妥當,那麼接下來就是讓你的快取目錄空空如也,且再也不寫入任何資料。 此外,也不要有多餘的記憶體來記錄熱門檔案啦!
如此一來,這部 proxy 就再也沒有快取了,全部資料都得要自己向外頭捉取!就不會有舊資料重複出現的問題∼ 17.4.3 Proxy 的認證設定 既然 proxy 有許多功用,包括分流的功能,很不賴啊!但是,由於網路閒人越來越多,因此 proxy 不可以設計為 open proxy !亦即是不能夠開放所有的人使用你的 proxy 啦!所以,一般來說, proxy 只會開放內部網域的人們來使用而已。 問題是,如果我在 Internet 也想要使用這部自己架設的 proxy 時,該如何是好?還得要再次的修改 squid.conf 嗎? 有沒有這麼麻煩? 沒關係啦!為了這個問題, squid 官方軟體已經給予了認證的設定功能!意即我們可以透過認證來簡單的輸入帳號密碼, 若通過驗證,就可以立刻使用我們的 proxy 了!這樣就好多啦!那如何達成呢?其實 squid 提供很多認證功能, 我們需要的是最簡單的功能即可。使用的是 squid 主動提供的 ncsa_auth 認證模組,這個模組會利用 apache (WWW 伺服器) 提供的帳密建立指令 (htpasswd) 所製作的密碼檔作為驗證依據。所以,我們至少需要檢查有沒有這兩樣東西:
這樣的事前準備就差不多了。讓我們來考慮一個案例好了:
那該如何處理呢?開始來一步一步進行吧:
比較需要注意『acl squid_user proxy_auth REQUIRED』這一串設定,proxy_auth 是關鍵字,而 REQUIRED 則是指定任何在密碼檔內的使用者都能夠使用驗證的意思。如果一切順利的話,那麼你的內網依舊可以使用 transparent proxy , 而外網則需要輸入帳密才能夠使用 proxy server 提供的代理能力。至於驗證的過程有點像這樣: 圖 17.4-1、使用 proxy 需驗證的示意圖 上圖中箭頭 1 為剛剛你設定的 real 內容,而帳密則是你用 htpasswd 所建立的資料啦!另外,既然已經加上了驗證功能, 那麼你可能得要將防火牆開放 port 3128 對全世界監聽的過濾才行呦!防火牆還是不要忘記了! ^_^ 17.4.4 末端登錄檔分析: sarg 事實上, squid 已經收集了眾多的登錄檔分析軟體了,而且大多是免費的 (http://www.squid-cache.org/Scripts/) ,你可以依照自己的喜好來加以安裝與分析你的 squid 登錄檔喔!鳥哥這裡僅介紹一套相當強的分析軟體, 那就是 sarg。 Squid Analysis Report Generator (Squid 分析報告製作者),他的官方網站在: http://sarg.sourceforge.net/sarg.php,他的原理相當的簡單,就是將 logfile 拿出來,然後進行一下解析,依據不同的時間、網站、與熱門網站等等來進行資料的輸出, 由於輸出的結果實在是太詳細了!所以...呵呵!如果你是老闆的話,用這個軟體會讓你『愛不釋手』啊! 因為每個人的每個小動作都會被記錄下來,我的天吶!當我第一次看到這個分析的畫面時,真的給他嚇了老大一跳得說∼因為連每個 IP 在『每個小時所連上的每個網站資料』都有紀錄∼∼害怕了吧∼ 不過,有優點就有缺點啦!怎麼說呢?因為 SARG 功能太強大了,所以記錄的『資料量』就實在是多了點,如果你的 Proxy 網站屬於那種很大流量的網站時,那麼就不要使用『日報表』,也就是每天產生一份報表的那種方式! 那麼由於資料一天可能會有幾 MB 的資料,一兩個月還沒有關係,如果記錄了幾年,那麼光是這些記錄就會花掉好幾 GB 的硬碟空間了∼此外,也可以使用『覆蓋舊有資料』的方式不要留存舊資料,這樣也可以節省硬碟的空間啦! 在 SARG 的官網上面已經有朋友替大家將 RPM 的檔案製作出來了,你可以參考:http://packages.sw.be/sarg/ 網站內的檔案。由於鳥哥用的是 CentOS 5.x 32 位元版本,因此下載的是 sarg-2.2.3.1-1.el5.rf.i386.rpm 這個穩定的版本。你可以使用 wget 下載到 /root 底下,再用 rpm -ivh 去安裝起來即可。 這個軟體預設會將 /var/www/sarg 作為輸出報表的目標,而且你必須要安裝與啟動 WWW 伺服器, 至於網址列則是: http://your.hostname/sarg 去查閱。底下讓我們來處理 sarg 的設定檔吧!
如果製作好相關資料,由於 sarg 這個 RPM 檔案已經幫我們設定好了每日、每週、每月進行一次執行, 所以你可以不用管怎麼執行啦!非常的方便!如果想要查閱資料,只要在 proxy server 端輸入 http://your.hostname/sarg 會看到如下畫面: 圖 17.4-2、sarg 報表觀察示意圖 如上所示,在網址列輸入伺服器本機的咚咚,然後會看到幾個連結。與我們有關的是 ONE-SHOT 以及 daily 兩個, 我們來瞧瞧 ONE-SHOT (箭頭 2 所指) 裡面有啥咚咚?按下去會看到下圖: 圖 17.4-3、sarg 報表觀察示意圖 如上圖所示,因為我們剛剛測試執行過兩次 sarg 的指令,所以這裡會有兩個時間的連結。我們先看看總和資料, 亦即圖中箭頭所指的地方,會出現下圖的說明: 圖 17.4-4、sarg 報表觀察示意圖 在該段時間內,共有三個用戶在存取,我們來瞧瞧 client.centos.vbird 到底幹了啥事吧! 圖 17.4-5、sarg 報表觀察示意圖 看到沒有,這個用戶在這段時間進行過的連線通通在裡面!有沒有很清晰呢? 17.5 重點回顧
17.6 本章習題 (尚未更新)
17.7 參考資料與延伸閱讀
2001/??/??:第一次完成日期,其實已經忘記了∼ 2001/11/09:加入增加 Proxy 效能的方法,就是使用多顆硬碟做成的資料儲存方式! 2003/04/04:完成大幅度的改寫動作!加入了完整的 Proxy 說明,與 pwebstats 的架設! 2003/04/11:完成了另一個末端分析的強大軟體 SARG 分析套件! 2003/09/16:微幅調校一下版面! 2004/11/12:修訂 transparent proxy 的設定問題, httpd_accel_with_proxy on 2011/03/31:將舊的基於好老的 Red Hat 9 的文章移動到 此處 2011/04/08:累死了∼這篇修改的幅度太大了!好疲倦∼ |
||||||||||||||||||||||||||||||||||||