■ 山東廣電網絡有限公司濟寧分公司 崔冬梅 韓磊

近期因受“新冠”疫情的影響，筆者單位處于半工作狀態(tài)，客服中心提出新需求，需要在家接聽用戶電話，并能登錄公司內網訪問業(yè)務支撐系統(tǒng)。

單位因先期在內外網之間部署過一臺防火墻，已經實現了互聯網用戶與業(yè)務支撐系統(tǒng)的互通。這次為了盡快實現該功能，我們的想法是繼續(xù)使用該方案通過路由和ACL進行訪問控制。但是在配置的過程中出現了外網用戶到業(yè)務支撐系統(tǒng)通但是到話務系統(tǒng)不通的故障，以下是網絡拓撲及排查過程。

網絡拓撲

通過圖1看出，網絡結構比較簡單，用戶需求是從外網PC可以訪問業(yè)務支撐系統(tǒng)及話務系統(tǒng)。

排查過程

圖1 整體網絡拓撲

設備的配置主要是路由和NAT，即在所經的三層設備上互指靜態(tài)路由，防火墻上針對trust和untrust做NAT及訪問控制，這里就不再敘述配置過程。

故障現象就是在外網PC可以ping通業(yè)務支撐系統(tǒng)，ping不通話務系統(tǒng)，通過tracert話務系統(tǒng)內網地址，路由只能到圖1中的內網交換機，但是可以正常訪問的業(yè)務支撐系統(tǒng)路由可以正常到達。經過反復檢查對比設備路由及防火墻的配置，沒發(fā)現與業(yè)務支撐系統(tǒng)配置不同的地方。

因為疫情影響，不便去現場抓包分析，既然路由已經到了內網交換機，所以分析故障點應該在內網交換機上，但通過檢查內網交換機配置，也沒有發(fā)現與業(yè)務支撐系統(tǒng)配置不同的地方。既然路由已到了該交換機，為什么沒有到話務系統(tǒng)？這是我們要排查的問題。

因話務系統(tǒng)有兩塊網卡，初步懷疑話務系統(tǒng)沒有設置網關或網關設置錯誤，但經排查話務系統(tǒng)網關設置完全正確。

接下來就要看看數據到了交換機后是否到了話務系統(tǒng)，以前我們使用交換機的流統(tǒng)功能處理過數據丟包的故障，流統(tǒng)就是通過在接口上應用ACL抓取源地址及目的地址的數據包收發(fā)情況，所以這次繼續(xù)使用流統(tǒng)看看數據包有沒有轉發(fā)給話務系統(tǒng)。

華為交換機的流統(tǒng)配置分為以下幾步：

1.定義ACL，配置流量統(tǒng)計的源與目的地址。

2.定義流分類，匹配ACL。

3.定義流行為。

4.定義流策略，綁定以上的流分類及流行為。

5.在端口應用流策略。

具體配置如下：

acl number 3001定義ACL

rule 1 permit ip source 10.*.247.242 0 destination 10.*.6.12 0

rule 2 permit ip source 10.*.6.12 0 destination 10.*.247.242 0//需要統(tǒng)計的流量,源做目的,目的做源.需要正反寫兩條rule條目，其中10.*。247.242為外網一主機，10.*.6.12為話務系統(tǒng)的一臺Linux系統(tǒng)服務器

traffic classifier test operator or precedence 10 定義名為test的流分類，優(yōu)先級為10

if-match acl 3001 綁定ACL3001

traffic behavior test定義流行為名為test

Permit 定義行為動作為允許

statistic enable 在流行為中開啟流量統(tǒng)計功能

traffic policy test match-order config 創(chuàng)建流策略名為test

classifier test behavior test 在流策略中匹配流分類及流行為

interface Gigabit Ethernet2/0/0 在流量進入交換機的接口和出交換機的接口上雙方向調用流策略，該端口為內網與防火墻連接端口

description HuaWei USG5000

port link-type access

port default vlan 200

loopback-detect enable

traffic-policy test inbound

traffic-policy test outbound

interface Gigabit Ethernet2/0/3 在交換機連話務系統(tǒng)的接口上雙方向調用流策略

description HuJiao ZhongXin

port link-type access

port default vlan 200

loopback-detect enable

traffic-policy test inbound

traffic-policy test outbound

首先在接話務系統(tǒng)的端口上應用了流策略，在外網服務器10.*.247.242上ping話務系統(tǒng)10.*.6.12的同時，在交換機上使用“display traffic policy statistics interface GigabitEthernet 2/0/3 inbound”查看端口流量統(tǒng)計信息，在出方向和入方向均為發(fā)現數據包存在，如圖2所示。接著又在內網交換機2/0/0上（與防火墻互聯接口）應用流策略，同樣也未發(fā)現數據包過來。

據此我們可以判斷數據沒有到達該交換機上，繼續(xù)向上級設備查找故障原因，通過在防火墻上查看會話表的信息，發(fā)現從10.*.247.242去往10.*.6.12的報文最終到了10.*.6.115,而沒有到達12這臺服務器上。

display firewall session table destination inside 10.66.6.12

icmp VPN:public-->public 10.*.247.242:1[10.*.6.115:2072]

根據該線索去防火墻上查找該10.*.6.115地址，通過排查發(fā)現該地址在源NAT中應用了“nat address-group index 0 name 內網地址 10.*.6.115 10.*.6.115”，該命令的意思是從外網訪問內網時NAT成內網地址10.*.6.115找了Web界面中的配置，如圖3所示。

將圖中源地址轉換為接口IP地址后業(yè)務恢復正常。但是筆者仍有疑問，為什么同樣的NAT，業(yè)務支撐系統(tǒng)正常呢？

再次返回內網交換機上查看路由發(fā)現，在內網交換機上與內網交換機2上起了OSPF，將10.*.6.0 255.255.255.0通過OSPF發(fā)布出去了，也就是說在業(yè)務支撐系統(tǒng)可以通過OSPF路由學習到10.*.6.115的路由，所以網絡可達，但是想訪問話務系統(tǒng)10.*.6.12，防火墻只會將源地址NAT成10.*.6.115，而10.*.6.115是防火墻上的一個虛地址，并非接口地址，這樣數據就不會再到話務系統(tǒng)了。

圖2 接口流量統(tǒng)計

圖3 防火墻的源NAT配置

當改成NAT成接口地址后，在防火墻及內網交換機上通過靜態(tài)路由可以正常到達話務系統(tǒng)。

結語

雖然只是一個小小的配置出了錯，但是在排查的過程中卻受了不少周折。網絡管理是一項全面而細致的工作，需要我們具備必要的理論知識及豐富的經驗，排查故障的思路一定要清晰，排查手段更是關鍵，就像本文中使用的交換機的流量統(tǒng)計，可以幫助我們判斷出故障點，免去抓包的繁瑣。

雖然網絡通了，但是仍存在一定的安全隱患，下一步我們將使用安全性較高的L2TP over IPSec VPN打通內外網。