威搜Fun

警告

威大使用的是中華電信-光世代-60M/15M，IP 開頭為 114，DNS 為中華電信（第一組）和 Google（第二、三組），不同網路結果可能不一樣。
另外，防火牆知識是臨時在網路上找資料和實驗所構成的，有錯還請小力的鞭給予糾正 ToT。

前幾個月，網路上流傳了一個秘方，擋掉中華電信快取伺服器（下面簡稱 Hinet 快取） 210.71.222.0/24，讓用戶直接連位於美國的 Youtube 伺服器（下面簡稱 Youtube 主機），看 Youtube 影片會比較順暢，不用苦苦等待影片緩衝，方法如下：

iptables -A OUTPUT -d 210.71.222.0/24 -j REJECT

netsh advfirewall firewall add rule name="BLOCKSLOWYOUTUBE" dir=in action=block remoteip=210.71.222.0/24 enable=yes

#補充說明：210.71.222.0/24 = 210.71.222.0 ~ 210.71.222.255

而現在又蹦出疑似新的 Hinet 快取，網段為 203.66.48.0/24，有不少人使用後表示 Youtube 順暢許多，不再卡卡了，

真的有這麼神奇？真的能避開 Hinet 快取而跑去 Youtube 主機？真的會變快？

另外，眼尖的看官應該發現 Linux 和 Windows 這兩條防火牆規則敘述並不是同一件事情，到底是怎麼回事呢？

威大為此粗略的實驗一下。

Windows 阻擋規則如同虛設

這裡使用了一款網路監控程式 “SmartSniff” 來看看阻擋前後的情況，阻擋前，Youtube 的影片是來自 Hinet 快取，

接下來新增防火牆規則來阻擋 Hinet 快取，

再次看看 Youtube 影片，

咦？怎麼還是來自 Hinet 快取？在試試看其他影片，

Youtube 影片依舊來自 Hinet 快取，這到底是怎麼回事？

先來看看防火牆規則，

netsh advfirewall firewall add rule name="BLOCKSLOWYOUTUBE" dir=in action=block remoteip=210.71.222.0/24 enable=yes

解釋一下，這是對防火牆新增一項規則，將規則命名為 “BLOCKSLOWYOUTUBE”，阻擋（action=block）來自遠端 Hinet 快取（remoteip=210.71.222.0/24）送往本地（dir=in）的封包，enables=yes 表示啟用這項規則。

既然這樣，為何本地還有辦法接收來自 Hinet 快取的封包，理論上會被防火牆擋掉才對，由於找不到相關資料，所以威大透過 Linux iptables 的經驗來推論，這規則只能阻擋來自遠端”新連線（NEW）”的封包，對於”已連線（ESTABLISHED）”的封包一般來說沒必要擋。

舉個例，我傳簡訊給朋友，朋友收到的簡訊就是一個”新連線”的封包，然後朋友傳了一封簡訊給我，我收到的這封簡訊是回應剛剛發出去的簡訊，所以是個”已連線”的封包，如果阻擋要求別人回應的簡訊豈不是很瞎。

實際用 Ping 的方式來看兩者差異導致的結果，首先 192.168.1.2 為本地主機 IP，192.168.1.30 為遠端主機 IP（可以想像是 Hinet 快取），在本地主機新增防火牆規則，

netsh advfirewall firewall add rule name="test" dir=in action=block remoteip=192.168.1.30 enable=yes

跟阻擋 Hinet 快取一樣的寫法，新增一項規則，將規則命名為 “test”，阻擋（action=block）來自遠端主機（remoteip=192.168.1.30）送往本地（dir=in）的封包，而這封包的狀態為”新連線”，enables=yes 表示啟用這項規則。

而遠端主機的防火牆規則是空的，所以接受所有連線，

接下來本地主機 Ping 192.168.1.30，

Ping 所使用的是 ICMP 協定，本地主機送出 echo request 封包給遠端說：喂，有人在家嗎？遠端防火牆認為這是一個”新連線”的封包，但沒有阻擋此封包的規則，所以放行，遠端主機收到此封包後，送出 echo reply 封包給本地說：我在家啦！本地防火牆發現來自遠端主機的封包，理應要被擋掉，但由於此封包是回應剛剛送出去的封包，視為”已連線”的封包，所以放行，本地主機收到封包後就將訊息顯示出來。

同樣手法在遠端主機上 Ping 192.168.1.2，結果得到以下的答案，

遠端主機送出 echo request 封包給本地說：喂，有人在家嗎？本地防火牆發現來自遠端主機的封包，而且是”新連線”封包，根據規則拒絕此封包，所以本地主機聽不到遠端的呼喊，也就沒必要回應遠端，遠端主機就收不到本地的訊息，因而產生此結果。

回到 Youtube 上，大家知道問題出在哪了吧，如果 Youtube 要求本地去 Hinet 快取下載影片，本地也很聽話地向 Hinet 快取索取影片，Hinet 快取當然很樂意將影片送來本地，本地也會很樂意的接收，因為對本地防火牆來說，這是回應剛剛送出去的封包，所以沒必要阻擋，造就了影片依舊來自 Hinet 快取。

換個思維想想，假如本地一開始就連不上快取伺服器，Youtube 是否會要求本地改去 Youtube 主機下載影片？

威大覺得這才是當初寫防火牆規則的想法，只是 Windows 的部分寫錯了，正確如下，

netsh advfirewall firewall add rule name="BLOCKSLOWYOUTUBE" dir=out action=block remoteip=210.71.222.0/24 enable=yes

對防火牆新增一項規則，將規則命名為 “BLOCKSLOWYOUTUBE”，阻擋（action=block）從本地送往（dir=out）遠端 Hinet 快取（remoteip=210.71.222.0/24）的封包且狀態為新連線，enables=yes 表示啟用這項規則，

重點就在 dir=out，表示本地送出的封包，而原本 dir=in 表示本地收到的封包，這做法會讓本地發給 Hinet 快取的封包全部擋掉。

防火牆添加後效果超群，再也看不到 Hinet 快取封包了，但是…..

悲劇發生了，有些影片無法緩衝，然後就發生錯誤了，重新整理網頁也無法解決，

雖然有一些影片可以正常瀏覽，影片封包來自 Youtube 主機，但絕大多數都不能看，

刪除防火牆規則就能正常瀏覽，而影片封包依舊來自 Hinet 快取，

威大無法解釋這種現象，只能推斷 Youtube 並不會因為本地連不到 Hinet 快取就轉到 Youtube 主機下載影片。

Linux 阻擋規則看不了 Youtube 影片

先來看看防火牆規則

iptables -A OUTPUT -d 210.71.222.0/24 -j REJECT
//建議 -A 改成 -I 將阻擋規則擺在最前面

從本地送出的封包（OUTPUT），封包目的地 210.71.222.0/24（Hinet 快取），把這種封包拒絕掉（-j REJECT），

現在知道為什麼一開始說 Windows 和 Linux 的防火牆規則敘述的不是同一件事情，因為前者阻擋”進來”的封包，後者阻擋”送出”的封包，

由於 iptables 可以讓使用者針對封包狀態進行設定，這條規則並沒有敘述，表示新連線、已連線等封包全部阻擋。

先跟大家說聲抱歉，這回沒有監控網路，只能透過分享器的連線監控來口述封包來源，

阻擋前，影片正常瀏覽，封包來自 Hinet 快取

新增防火牆規則阻擋快取伺服器後，結果跟 Windows 一樣悲劇，剛剛還可以看的影片都發生錯誤了，

還是有些影片是可以正常瀏覽，封包來自 Youtube 主機，

刪除規則後，影片又可以正常瀏覽了，至於原因是啥，應該跟 Windows 一樣的道理。

分享器阻擋規則可能也如同虛設

家中分享器已經刷了 Tomato 或是 DD-WRT 的韌體可以使用 iptables 來新增防火牆規則，畢竟底層系統是 Linux，但防火牆規則不能照抄 Linux，需要修改成

iptables -I FORWARD -d 210.71.222.0/24 -j REJECT

簡單說明 OUTPUT 改成 FORWARD 的原因，

iptables 的 filter tables（過濾表）由 INPUT、FORWARD、OUTPUT 所構成，假如封包目的地是分享器本身，送到 INPUT 進行規則判斷，然後由分享器本身的程序去解封包；如果分享器本身的程序發送封包出去，先送到 OUTPUT 進行規則判斷，然後送出；如果封包只是經過分享器，目的地是其他地方（例如接在分享器上的電腦），封包會送到 FORWARD 進行規則判斷，然後送出。

所以，當分享器上的電腦瀏覽 Youtube 影片時，所有往返的封包目的地都不是分享器本身，只是經過而已，如果要阻擋封包，要在 FORWARD 下達規則才行，這就是 OUTPUT 改成 FORWARD 的原因，寫在 OUTPUT 根本擋不到。

設定好後，結果跟 Windows 和 Linux 一樣無法正常瀏覽 Youtube 影片，就不再貼圖敘述了。

至於用 web 介面設定防火牆規則的，不同廠牌設定的方式可能有些微差別，如果成功阻擋，結果應該跟 Windows 和 Linux 一樣，可以用網路監控軟體來驗證。

總結

綜合以上所述，歸類出以下結論：

1. 原先 Windows 防火牆規則根本無法阻擋 Hinet 快取伺服器，導致 Youtube 影片依舊來自 Hinet 快取伺服器。
2. 承第一點，使用後覺得 Youtube 影片速度變快應該是心理作用或其他巧合。
3. 修正後的 Windows 防火牆規則成功阻擋 Hinet 快取伺服器，但似乎不會轉到美國 Youtube 伺服器，可能導致 Youtube 影片無法正常瀏覽。
4. 在分享器上使用 iptables -A OUTPUT 新增防火牆規則無法阻擋快取伺服器的封包，結果跟第一點一樣。
5. 承第四點，將 OUTPUT 修正為 FORWARD 成功阻擋 Hinet 快取伺服器，但結果跟第三點一樣。
6. Linux 防火牆規則成功阻擋 Hinet 快取伺服器，但結果跟第三點一樣。
7. Youtube 影片並不全然從 Hinet 快取伺服器進行下載，有時直接連到美國 Youtube 伺服器（即便同一部影片），判斷規則不明。
8. 承第三、五、六點，偶爾重新整理網頁後可以正常瀏覽影片，此時封包來自美國 Youtube 伺服器，但重整後又失敗了，判斷規則不明。
9. Hinet 快取伺服器不一定比美國 Youtube 伺服器還來的慢，一切都要看當時的情況
10. 時間比較長的影片會快速緩衝一小段，之後慢慢緩衝，應該是要節省頻寬