■ 湖南工業大學現代教育技術中心 郭兆宏
編者按: 筆者單位近期遇到某個網站部分公網IP打不開,最后經過排查發現是因為曾經在刪除映射后但相關的ACL規則沒有刪除,造成此類故障。
單位某部門反應一個網站218.X.X.123:83打不開,筆者馬上在辦公室測試,可以打開此網站內網地址:172.x.x.75及公網地址218.X.X.123:83,而在 www.17ce.com上測試確實有些站點打不開,而測試單位門戶網站基本全能打開,在出口設備上也可查到此網站內外網地址的流表,只能解釋說內網正常,外網沒辦法查,且單位門戶網站是正常的。
下班在家里確實也打不開 218.X.X.123:83,而以前可以正常打開的,遠程到單位查看出口流表,家里測出的公網的IP地址流表的源地址及目的可以查到,有發送字節數,但沒有接收字節數,于是開始排查起來。
在出口上增加映射172.x.x.75:80到218.x.x.121:2283(電信線路上的映射)及172.x.x.75:80到 58.x.x.220:2283(聯 通線路上的映射),在家里都無法打開218.x.x.121:2283、58.x.x.220:2283,用www.17ce.com測試只有部分站點打不開,大部分站點可以打開。用上一次故障排查的映射172.x.x.11到218.x.x121:8080,先 打 開此網站正常,用www.17ce.com測試基本全能打開,然后更改這個映射的內網地址為172.x.x.75:80到218.x.x.121:8080,此 時 打不 開218.x.x.121:8080,用www.17ce.com測試有部分站點打不開,改映射為172.x.x.11:80到218.x.x.123:83,在家打開正常,在www.17ce.com上測試基本全能打開,再把單位門戶網站的內網映射到218.X.X.123:83,測試 基 本 全能打開,判定公網IP:218.x.x.123地址及端口號83是正常的沒有被封禁,可能是內網哪里有問題。
確認公網IP地址及端口號都是正常的,感覺是內網有問題。在上網行為日志中心單用戶分析中按月查IP地址172.x.x.75平均每天有4萬次訪問,峰值有8萬多,同時查單位門戶網站IP地址172.x.x.101,平均每天有15萬,峰值有22萬多,因日志中心統計的數據是滯后的不是實時的數據,記得此網站以前訪問量最高峰時一天有六十萬多次的訪問量,這個峰值比單位門戶網站的訪問量的峰值大得多,會不會最近訪問量太大?

圖1 sh ip fpm flows | include 218.x.x.116 (172.x.x.75) 所顯示的數據
在出口查此IP172.x.x.75會話數sh flow-premgr ip-info 172.X.x.75 只有幾十個,而sh flow-premgr ip-info 172.X.x.101有幾個百個,為172.x.x.75修改每秒新建連接數為最大值10萬個,測試故障依舊,最后選擇是0為不限制,測試后故障依舊,發現用www.17ce.com測試打不開的站點的在出口流表上,sh ip fpm flows | include 218.x.x.123 (172.x.x.75)有發送字節數,但沒有接收字節數,srcif、dstif數據都是(ffff),如圖 1,判定是安全設備哪里有阻斷。
核心網絡里串接了多臺安全設備,在WAF里發現有幾百條172.x.x.75的相關記錄,馬上增加對172.x.x.75的放通,其他安全設備的日志沒有找到172.X.X.75的記錄,在防火墻上增加對17.x.x.75的放通,策略計數一會就達到9999+了,再查日志發現有大量的172.x.x.75的記錄,其中有一些是不完整會話,其中有個IP地址正是在出口流表查 到 srcif、dstif數 據 有(FFFF)的,說明數據過來了,但沒有返回去。對多臺安全設備都增加了對172.x.x.75的放通,檢查日志阻斷里都沒有對172.x.x.75的阻斷,可測試后故障依舊。沒辦法一臺臺直接跳過安全設備,數臺安全設備全跳過后可故障依舊,測試打開218.x.x.123:83還是有部分站點無法打開,判定故障與安全設備無關,可能是網站及服務器哪里有問題。
判定此網站及服務器可能有問題后讓此部門檢查服務器,查下訪問日志,尤其是出口流表上有(FFFF)的記錄IP地址訪問數據,可等了半天他們也沒提供出數據來。
沒辦法先把此部門的服務器的網絡關閉了,找一臺自用的服務器克隆某一網站使用此網站IP地址172.x.x.75,再次測試內網 IP、公網IP在辦公室打開都正 常,用www.17ce.com測試故障依舊還是有部分站點打不開,同時傳來在家所在小區也是單位大部分人住的小區可以打開此網站 218..x.x.123:83了(在斷網之前)。在出口流表上查看到sh ip fpm flows |include 218.x.x.123 (172.x.x.75)的 srcif、dstif數據有(FFFF)的幾個公網IP地址,在克隆網站的訪問日志里都沒有查找到,而出口流表里sh ip fpm flows |include 218.x.x.123 (172.x.x.75)有收發數據的幾個公網IP地址,在克隆服務器的訪問日志里全能找到。更改克隆服務器的IP地址為172.x.x.175,同時更改映射172.x.x.175:80到218.75.197.123:83,在www.17ce.com測試基本全能打開了,在出口里查流表sh ip fpm flows | include 218.x.x.123 (172.x.x.175)收發都有數據了,srcif、dstif沒看到有(FFFF)的了。判定網站及服務器應沒有問題,應是IP地址172.x.x.75在網絡哪里有問題。
因單位網絡是從辦公核心交換機到學生核心交換機后先走學生宿舍的三家運營商的三臺路由器上,默認的數據再從一臺路由器走辦公出口網關上,單位網絡拓撲圖如圖2。想在核心交換機上抓包看看但查看下最后放棄了,一個因為核心交換機上沒有空白萬兆端口了只有千兆端口,二個因為到三臺路由器的4個接口流量至少都有1個G,上班時都是數個G,峰值近10G,千兆口鏡像下來肯定丟包,只得放棄抓包。

圖2 單位網絡拓撲圖
核心交換機上沒有查到與172.x.x.75相關的配置,到此網站幾臺交換機里也沒查到與172.x.x.75相關的配置。登錄三臺宿舍路由器,發現有一臺路由器的有一個ACL上面有允許172.x.x.75的,即到這臺路由器這條策略上的數據從學生宿舍某運營商出口出去了,不走默認的辦公出口,刪除些條規則后,其它2臺路由器沒有發現與172.x.x.75相關的內容,使用克隆服務器用IP地址172.x.x.75,映射用 218.x.x.123:83,用www.17ce.com測 試218.X.X.123:83基本全能打開了,在出口里查流表sh ip fpm flows| include 218.x.x.123(172.x.x.75)收發都有數據了,srcif、dstif沒看到有(FFFF)的了。然后關閉克隆服務器的網絡,打開此部門網站172..x.x.75的網絡,再次測試都是正常的了,至此故障解決。
是因為幾個月前此部門此網站訪問巨大有六十多萬次,且有時打不開,于是就增加了某學生宿舍出口的映射,但測試后發現不好用,就刪除了映射,但相關的ACL規則沒有刪除,從公網過來訪問此網站的經過此路由器此條規則的數據就走學生宿舍某運營商出口了,沒有返回到辦公出口去,這就是為什么在辦公出口查到不能訪問IP的流表里只有發送數據沒有接收數據的原因。
因從辦公出出口進來的數據分別走三臺宿舍路由器再到學生核心交換機,每臺路由器都有三個選出口策略路由,且只有一臺路由器的一個ACL有允許172.x.x.75規則的,即走學生出口了,所以只有極少數訪問不成功,且數據是隨機走三臺路由器,這也是有時能訪問有時不能訪問的原因,并不是安全的原因。