引言： 本文介紹一則由策略路由引起的故障及排除過程，期間抓包驗證“數(shù)據(jù)包來回路徑不一致”被防火墻檢測丟棄的現(xiàn)象。本文重點分享了解決網(wǎng)絡(luò)疑難問題的過程與方法，并給出一種在防火墻存在狀態(tài)下不影響源端網(wǎng)段間互訪的策略路由寫法。

故障現(xiàn)象

一天，某單位資深工程師給筆者打了求助電話，起因是該單位外網(wǎng)內(nèi)部分網(wǎng)段無法訪問局域網(wǎng)內(nèi)系統(tǒng)，但均能上互聯(lián)網(wǎng)辦公。在筆者的要求下，工程師畫了該單位外網(wǎng)的簡單拓撲圖如圖1所示。

該單位外網(wǎng)采用高可用性網(wǎng)絡(luò)架構(gòu)。出口采用電信運營商和政務(wù)網(wǎng)雙出口冗余熱備；核心層采用虛擬化技術(shù)，由兩臺國產(chǎn)H3C 7500系列高端交換機IRF虛擬化成一臺交換機；接入層（服務(wù)器區(qū)）采用多模光纖聚合鏈路上聯(lián)?，F(xiàn)在的現(xiàn)象是：某些網(wǎng)段（如172.18.49.0/24網(wǎng)段下）的計算機無法訪問172.18.54.0/24網(wǎng)段下的服務(wù)器，無 法Ping通，但是該核心交換機下的其他網(wǎng)段卻正常，并且所有網(wǎng)段均能上網(wǎng)。

故障分析

這個網(wǎng)絡(luò)架構(gòu)屬于經(jīng)典的網(wǎng)絡(luò)架構(gòu)圖。核心交換機（可以看成一個交換機）下面的網(wǎng)段同屬于一個交換區(qū)，如果沒有特別的網(wǎng)絡(luò)策略或防火墻，理論上，互通沒有任何問題（H3C交換機默認是開啟網(wǎng)段間路由的）。問題出現(xiàn)了，本著“分析驗證”的思路，逐步開展以下分析。

1.排除服務(wù)器區(qū)域故障點

部分網(wǎng)段能訪問服務(wù)器區(qū)網(wǎng)段，說明服務(wù)器服務(wù)應(yīng)該正常。該工程師還給筆者強調(diào)前幾天還是正常的，期間沒人動過服務(wù)器配置，這使筆者暫時排除服務(wù)器及服務(wù)器所在網(wǎng)段的設(shè)備問題。

2.排除接入網(wǎng)段故障

故障點所在的接入交換機網(wǎng)段能夠正常上網(wǎng)，說明接入交換機的設(shè)備和網(wǎng)路也應(yīng)正常。

3.排除核心交換機故障

有網(wǎng)段能訪問，說明核心交換機網(wǎng)段間路由是沒被關(guān)閉的。再說，該工程師強調(diào)“前幾天都正?！薄ⅰ熬W(wǎng)段間是直接鏈路聚合上聯(lián)交換機的”、“沒有網(wǎng)絡(luò)阻攔策略和防火墻”。如果這樣的話，理論上沒問題。

圖1 外網(wǎng)拓撲簡圖

圖2 原數(shù)據(jù)包流圖分析

筆者要求遠程查看核心交換機的配置，發(fā)現(xiàn)該單位為了流量負載均衡，部分網(wǎng)段采用了策略路由配置。在核心交換機上定義策略DianXinPre，為類DianXin指定流行為DianXinBehavior（下一跳為電信路由接口），為類ZhenWu指定流行為ZhenWuBehavior（下一跳為政務(wù)路由接口）。和故障網(wǎng)段相關(guān)的配置信息簡述如下：

#通過Acl匹配，定義不同數(shù)據(jù)流向的類

# 定義不同類的下一跳數(shù)據(jù)路徑

redirect next-hop 電信路由下聯(lián)口IP

traffic behavior ZhenWuBehavior

redirect next-hop 政務(wù)路由下聯(lián)口IP

#把類和特定流向關(guān)聯(lián)，形成策略

4.排除策略路由配置錯誤

看到目標網(wǎng)段有策略路由配置，我們知道，策略路由的優(yōu)先級高于靜態(tài)路由，莫非數(shù)據(jù)包從接入交換機上聯(lián)口進入核心交換機時，被直接策略轉(zhuǎn)向電信路由器后沒有回包，導致無法被Ping通？我繪制了如圖2所示的數(shù)據(jù)包流圖。

172.18.49.0/24 ping 172.18.54.0/24數(shù)據(jù)包流圖沿虛線流向，數(shù)據(jù)包沿虛線①-②方向到目標網(wǎng)段，目標網(wǎng)段因為有策略路由，故回包沿③先到電信路由器（不是直接通過核心交換機轉(zhuǎn)給源端），然后電信路由器要寫條目的為172.18.49.0/24的回程靜態(tài)路由指向核心交換機（即線路④）返回到核心交換機，然后再沿線路⑤回包到源端。問題有可能出現(xiàn)在線路④上。

可是，經(jīng)驗老道的工程師當時就打消了我的疑問。工程師說，這點他還是知道的，明確有回程路由，否則前幾天不會通。在我的要求下，他自己又登錄設(shè)備驗證了有回程路由。

分析陷入了僵局，筆者要求分別從源端和目的端抓包分析（如圖3和圖4）。

圖3 源端抓包

圖4 目的端抓包

圖5 新數(shù)據(jù)包流圖分析

由圖3和圖4可以看出，源端發(fā)包只有request包，就是沒有服務(wù)器響應(yīng)包，無法建立TCP連接，而服務(wù)器端抓包正常（能Ping通源地址）。原因已經(jīng)很明確了，源地址在訪問服務(wù)器的時候，服務(wù)器端沒有回程數(shù)據(jù)包！

可是，工程師不承認上面的分析。筆者要求，遠程桌面親自查看，工程師登錄了設(shè)備，原來是一臺某大廠商的防火墻，并找出回程靜態(tài)路由配置。筆者問，不是說是路由器嗎，怎么會是防火墻？工程師說，上個星期把出口換成防火墻了，但路由器的配置一一對應(yīng)遷移到防火墻了，后來測試“一切”正常。一看到防火墻，筆者猶豫了，是不是有什么阻攔策略呢？查看發(fā)現(xiàn)，回程靜態(tài)路由確實存在并且正確。問題出在哪里呢？

再次結(jié)合數(shù)據(jù)包流圖分析過程并特別留意服務(wù)器回程的數(shù)據(jù)包，問題突然豁然開朗。

如 圖5所 示，172.18.49.0/24 沿虛線①-②傳輸數(shù)據(jù)包，由于172.18.54.0/24網(wǎng)段做策略路由，優(yōu)先級高于靜態(tài)路由，回包被策略到電信出口防火墻，由于是狀態(tài)檢測包過濾的防火墻，事先沒有請求包通過而直接返回數(shù)據(jù)包，防火墻認為是攻擊行為，故直接攔截掉了。筆者啟用了該防火墻的非狀態(tài)檢測包過濾功能，困擾該工程師的難題立刻解決了。

為什么一開始服務(wù)器端卻能Ping通客戶端呢？其實，很好理解。服務(wù)器發(fā)起的訪問包被策略路由沿虛線③轉(zhuǎn)發(fā)到防火墻（防火墻對合理的請求包是允許通過的），然后通過靜態(tài)路由沿虛線④到核心交換機，后到客戶端；客戶端回包，直接通過核心交換機返回到服務(wù)器端，一次通信連接順理成章地建立成功。

故障解決

知道問題原因，故障暫時解決了?？墒?，該工程師說，這不是長久的解決辦法，啟用防火墻的非狀態(tài)檢測包過濾功能就意味著防火墻的部分安全功能被廢棄了。

確實如此，策略服務(wù)器網(wǎng)段的業(yè)務(wù)需求不能改變（因為外網(wǎng)發(fā)布需要），其他網(wǎng)段的需求也不能妥協(xié)，能否有兼顧的解決辦法呢？登錄虛擬化的核心交換機并查看相關(guān)廠家文檔，研究后給出一種在防火墻存在狀態(tài)下不影響源端網(wǎng)段間互訪的策略路由寫法：

在原策略路由基礎(chǔ)上新增類Lan（到本地局域網(wǎng)網(wǎng)段的數(shù)據(jù)流），指定流行為LanBehavior（采用流量過濾filter permit，而不是定義下一跳地址），然后在策略DianXinPre的首條增加Lan和LanBehavior的關(guān)聯(lián)。

#通過Acl匹配，新增本局域網(wǎng)網(wǎng)段間數(shù)據(jù)流的類

#對本局域網(wǎng)網(wǎng)段間的流量采用流量過濾，而不是定義下一跳地址

#在策略中首先匹配局域網(wǎng)內(nèi)數(shù)據(jù)流量

至此，故障完全解決。筆者在原來配置的基礎(chǔ)上加了特定局域網(wǎng)內(nèi)網(wǎng)段的數(shù)據(jù)包流量過濾的寫法。凡是目的為局域網(wǎng)內(nèi)部網(wǎng)段（ACL 3000匹配）的數(shù)據(jù)包，流行為是允許，并在策略的第一條不讓交換機給“扔”到上聯(lián)防火墻（或路由器）。H3C或華為設(shè)備的策略路由“流行為”，是對應(yīng)符合流分類的報文做出相應(yīng)的QoS動作，例如流量監(jiān)管、流量過濾、流量重定向、重標記、流量統(tǒng)計等。而平時，大家多用流量重定向（redirect nexthop IP），對流量過濾則很少使用，相關(guān)資料也很少提及，但這個功能是非常重要的。還有一點需要強調(diào)，在定義策略中為類指定采用的流行 為（classifier tcl-name behavior behavior-name）是從上向下匹配執(zhí)行的，上下順序也極為重要，不能顛倒。

經(jīng)驗總結(jié)

1.數(shù)據(jù)包來回路徑不一致可以正常通信，不影響業(yè)務(wù)。但是中間有防火墻就會有例外就有可能會被阻攔（沒請求經(jīng)過而直接返回的連接會被攔截）。

2.策略路由寫法不全面不縝密，歸根結(jié)底是對策略路由技術(shù)理解的不夠到位不夠深刻。

出現(xiàn)問題，要根據(jù)數(shù)據(jù)包流圖冷靜分析，不要被“原來‘一切’正?！?、“確定沒問題”、“我驗證過”所遮目，逐步分析每一個可能的故障點。以前一個小小的配置修改或者設(shè)備變動就會為日后的故障埋下伏筆，特別是變更后問題沒有及時發(fā)現(xiàn)，一段時間后才發(fā)現(xiàn)的故障，更難察覺。隨著信息化發(fā)展的規(guī)?；碗s化，只有不斷學習才能更好地適應(yīng)形勢發(fā)展要求。