本文檔不是講述如何用網絡分析工具去解決防火墻路由配置錯誤，而是用簡單的系統工具和基本路由知識通過現象分析問題并解決問題，并通過該過程總結遇到網絡問題我們解決的思路。適合于剛接觸防火墻和交換路由設備的XDJM們。
前置知識：
基礎路由知識；
會在dos界面輸入tracert及ip地址。
網絡架構：
該企業現有的架構較簡單，沒有設置DMZ區，僅僅使用防火墻進行上網訪問控制，物理連接和地址分配如上拓撲圖。其中內部網將172.15.0.0/16進行子網劃分成24個子網，對應不同的廠區部門所在的VLAN。
一、事故起因及現象
國慶后的一天，該外地用戶打電話給俺，說剛對9月份部署的一臺防火墻在做了策略調整后整個公司不能訪問互聯網，導致全廠職工和領導極大的不滿，聯名說周一前弄不好就扣信息中心的工資。。。。。。（幸虧俺RP好，不是在十一期間調整 ^_^）通過咨詢，了解現在的網絡狀況表現如下：
1、不能通過域名上網，也不能通過已知的外網網站的ip上網，但是可以ping通外網的地址；（注意！此處位為用戶的說法）
2、可以登陸到該防火墻進行策略的調整設置；
二、遠程分析診斷
根據用戶所描述的現象，初步判斷為DNS服務器沒有起效，因此讓他們看看防火墻設置中的DNS服務器地址是否正確，能否ping通該服務器。回答是防火墻中設置的DNS服務器的地址是當地電信提供的，但是無法ping通到該dns地址。
根據以上ping當地DNS服務器地址不通的結果，以及用戶提到可以ping通外網地址，分析為當地的dns服務器服務可能有中斷。準備叫他們換其它dns服務器進行嘗試，并尋求他們該防火墻的管理員密碼以進行更加詳細的設置查詢和設置，但是他們以公司內部機密等原因不提供，并希望我們到現場進行解決。
沒有辦法，只有去一趟咯！
公司－－的士－－源長途車站－－睡覺2小時－－目標長途車站－－的士－－現場
三、現場分析處理
到達現場后，對客戶描述的現象進行測試：
1、整個企業內部網網絡連通正常；
2、任何網段中允許上網的工作站無法通過域名訪問互聯網；
3、任何網段中允許上網的工作站無法通過已知的IP訪問互聯網網站及其它服務；
4、任何網段中允許上網的工作站能ping通到防火墻外網口網關（即電信端）；
5、任何網段中允許上網的工作站無法ping通到電信端以外的地址（此處跟用戶最先說的可以ping通外網的ip地址不符合。后經了解，用戶當時以為能ping通到電信端就以為是ping通到外網所有的地址，沒有進行進一步的測試。）
根據以上的表象，初步認為有兩種可能：
1、電信端出問題，該公司所處的公網網段地址沒有發布出去；
2、本地的防火墻設置有問題。
為了進一步進行查詢問題出在什么地方，決定進行一次路由跟蹤，看是否是電信端的關于該企業的公網網段發布問題。
tracert 61.172.255.19 （www.netexpert.cn的解析地址，允許ping，實在是測試網絡設置效果時的必備之暗器）
Tracing route to www.netexpert.cn [61.172.255.19] over a maximum of 30 hops: 1 3 ms <1 ms <1 ms 172.15.0.254 （本機網關） 2 6 ms 99 ms 102 ms 172.16.0.250 （防火墻內網口） 3 257 ms 300 ms 317 ms 216.X.X.241 （防火墻外網口網關，電信） 4 298 ms 141 ms 128 ms 221.232.254.1 5 188 ms 265 ms 387 ms 202.97.37.149 6 270 ms 130 ms 79 ms 202.97.35.77 7 490 ms 372 ms 495 ms 61.152.86.13 8 102 ms 91 ms 87 ms 61.152.87.134 9 41 ms 46 ms 95 ms 61.152.83.38 10 89 ms 252 ms 81 ms 61.152.83.162 11 304 ms 333 ms 439 ms 218.78.213.102 12 448 ms 463 ms 173 ms 61.172.255.19 |
從以上結果，我們可以看是防火墻的對目的為61.172.255.19的數據包沒有正確的路由，數據在交換機和防火墻之間進行環路傳遞。
確定是防火墻的路由有問題，登陸到該防火墻，查詢路由狀態：
Yty-> get route
untrust-vr (0 entries)
--------------------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R – RIP trust-vr (4 entries)
--------------------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 5 0.0.0.0/0 eth1 172.16.0.254 S 20 1 Root
* 3 0.0.0.0/0 eth3 216.X.X.241 S 20 1 Root
* 1 172.16.0.0/24 eth1 0.0.0.0 C 0 0 Root
* 2 216.X.X.240/28 eth3 0.0.0.0 C 0 0 Root#p#副標題#e#
從上表中，我們可以看到除了有兩條直聯路由外，配置了兩條默認路由，到達未知IP可通過E1或E3到達，而且訪問回來的路由沒有，看來問題應當出在這個地方了。
讓我們來假設一下數據報的流向：
1、訪問目標為路由已知的地址
采用此路由表，我們在內網中能訪問到的最遠的地址為該企業專線在電信端的地址，即216.X.X.241/28。其流向為工作站―――工作站網關（vlan地址）―――所在vlan網關（交換機同防火墻直聯端口地址172.16.0.254）―――防火墻內網口地址（172.16.0.250），防火墻通過路由表查詢，發現到達216.X.X.241的地址為自己的直聯路由，將該數據報交給E3,這樣我們訪問的數據報能到達該地址。
2、訪問目標為路由未知的地址
在訪問目標為路由未知的地址時，數據報到達E1后，E1發現有兩條默認路由，因此將數據重新轉發到交換機（為什么不選用另一默認路由未知？難道是針對E1口而言這條默認路由的優先級高一些？尋求答案！），交換機根據自己的路由表又發到防火墻，而防火墻根據路由表又發回。。。。。。，最終導致路由環路。
后經了解，負責防火墻的管理人員為了讓返回的數據包到達目的，將原有的路由表進行勒修改，增加了這條造成環路的路由。
原路由設置為：
set route 0.0.0.0/0 interface ethernet3 gateway 216.x.x.241 set route 172.15.13.0/24 interface ethernet1 gateway 172.16.101.254 set route 172.15.3.0/24 interface ethernet1 gateway 172.16.101.254 （原來只允許13和3兩個VLAN訪問互聯網） |
錯誤的路由設置為：
set route 0.0.0.0/0 interface ethernet3 gateway 216.x.x.241 set route 0.0.0.0/0 interface ethernet1 gateway 172.16.101.254 |
四、故障處理
將路由 0.0.0.0/0 eth1 172.16.0.254 S 20 1 Root刪除;
重新添加新的路由條目：
* 4 100.0.0.0/8 eth1 172.16.0.254 S 20 1 Root
（回應包路由，到達100.0.0.0網段的數據報將交給Eeh1處理，下一跳的地址為交換機到防火墻的級聯口）
* 5 172.15.0.0/16 eth1 172.16.0.254 S 20 1 Root
（回應包路由，到達172.15.0.0/16的任一網段的數據將轉發到eth1，下一跳地址為交換機端口地址。）
set route 0.0.0.0/0 interface ethernet3 gateway 216.x.x.241 set route 100.100.10.0/8 interface ethernet1 gateway 172.16.101.254 set route 172.15.0.0/16 interface ethernet1 gateway 172.16.101.254 |
查詢路由
yty-> get route
untrust-vr (0 entries)
--------------------------------------------------------------------------------
C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP
trust-vr (5 entries)
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------
* 3 0.0.0.0/0 eth3 216.X.X.241 S 20 1 Root
* 1 172.16.0.0/24 eth1 0.0.0.0 C 0 0 Root
* 2 216.X.X.240/28 eth3 0.0.0.0 C 0 0 Root
* 4 100.0.0.0/8 eth1 172.16.0.254 S 20 1 Root
* 5 172.15.0.0/16 eth1 172.16.0.254 S 20 1 Root
五、結果測試
Tracing route to www.netexpert.cn [61.172.255.19]
over a maximum of 30 hops:
1 3 ms <1 ms <1 ms 172.15.0.254 （本機網關）
2 6 ms 99 ms 102 ms 172.16.0.250 （防火墻內網口）
3 257 ms 300 ms 317 ms 216.X.X.241 （防火墻外網口網關，電信）
4 298 ms 141 ms 128 ms 221.232.254.1
5 188 ms 265 ms 387 ms 202.97.37.149
6 270 ms 130 ms 79 ms 202.97.35.77
7 490 ms 372 ms 495 ms 61.152.86.13
8 102 ms 91 ms 87 ms 61.152.87.134
9 41 ms 46 ms 95 ms 61.152.83.38
10 89 ms 252 ms 81 ms 61.152.83.162
11 304 ms 333 ms 439 ms 218.78.213.102
12 448 ms 463 ms 173 ms 61.172.255.19
至此問題解決，將工作站劃分到不同vlan上網都正常。
總結
對故障的排除并不一定需要專業的網絡分析軟件，很多系統自帶的工具能很方便的反映問題所在，定義問題點，此次能找到問題點就是因為使用tracert進行路由跟蹤，確定了故障的原因是環路路由造成的；
網絡出現故障時一定要對網絡的架構有所了解，根據問題表現按照網絡連接的順序進行正向、反向的驗證、分析，找出故障所在。
對于問題出在三層交換、網關位置時，問題一般是數據報路由的問題，因此出現故障首先檢查路由表，這樣會省很多事情；
對于故障現象應當進行驗證操作，以免出現實際和描述不一致的地方，影響故障診斷。
后語
每次處理問題后，總有種沖動，想寫些東西，不為別的，只是想將該處理方法回味一下，確認自己確實是了解該故障原因和處理方法是否正確。不想做那種知道處理方法而不知道原因的操作工。由于一直做防毒方面的工作，考試結束后就沒有接觸什么路由交換的東東，因此這次的沖動更強烈些，就亂七八糟的寫了一通，也不知對否，望論壇中的XDJM們拍磚，俺挺得住的！
這次的處理問題時還有很多地方自己沒有弄清楚，所以沒有寫得很詳細。比如數據報在訪問過程中的數據格式、到達目的地址后的回應包的格式、在設置兩條默認路由情況下數據報會如何選擇等問題。希望各位兄弟姐妹們多多指教！
