巧用交换机流统功能判断网络故障

■ 山东广电网络有限公司济宁分公司 崔冬梅 韩磊

近期因受“新冠”疫情的影响，笔者单位处于半工作状态，客服中心提出新需求，需要在家接听用户电话，并能登录公司内网访问业务支撑系统。

单位因先期在内外网之间部署过一台防火墙，已经实现了互联网用户与业务支撑系统的互通。这次为了尽快实现该功能，我们的想法是继续使用该方案通过路由和ACL进行访问控制。但是在配置的过程中出现了外网用户到业务支撑系统通但是到话务系统不通的故障，以下是网络拓扑及排查过程。

网络拓扑

通过图1看出，网络结构比较简单，用户需求是从外网PC可以访问业务支撑系统及话务系统。

排查过程

图1 整体网络拓扑

设备的配置主要是路由和NAT，即在所经的三层设备上互指静态路由，防火墙上针对trust和untrust做NAT及访问控制，这里就不再叙述配置过程。

故障现象就是在外网PC可以ping通业务支撑系统，ping不通话务系统，通过tracert话务系统内网地址，路由只能到图1中的内网交换机，但是可以正常访问的业务支撑系统路由可以正常到达。经过反复检查对比设备路由及防火墙的配置，没发现与业务支撑系统配置不同的地方。

因为疫情影响，不便去现场抓包分析，既然路由已经到了内网交换机，所以分析故障点应该在内网交换机上，但通过检查内网交换机配置，也没有发现与业务支撑系统配置不同的地方。既然路由已到了该交换机，为什么没有到话务系统？这是我们要排查的问题。

因话务系统有两块网卡，初步怀疑话务系统没有设置网关或网关设置错误，但经排查话务系统网关设置完全正确。

接下来就要看看数据到了交换机后是否到了话务系统，以前我们使用交换机的流统功能处理过数据丢包的故障，流统就是通过在接口上应用ACL抓取源地址及目的地址的数据包收发情况，所以这次继续使用流统看看数据包有没有转发给话务系统。

华为交换机的流统配置分为以下几步：

1.定义ACL，配置流量统计的源与目的地址。

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//需要统计的流量,源做目的,目的做源.需要正反写两条rule条目，其中10.*。247.242为外网一主机，10.*.6.12为话务系统的一台Linux系统服务器

traffic classifier test operator or precedence 10 定义名为test的流分类，优先级为10

if-match acl 3001 绑定ACL3001

traffic behavior test定义流行为名为test

Permit 定义行为动作为允许

statistic enable 在流行为中开启流量统计功能

traffic policy test match-order config 创建流策略名为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 在交换机连话务系统的接口上双方向调用流策略

description HuJiao ZhongXin

port link-type access

port default vlan 200

loopback-detect enable

traffic-policy test inbound

traffic-policy test outbound

首先在接话务系统的端口上应用了流策略，在外网服务器10.*.247.242上ping话务系统10.*.6.12的同时，在交换机上使用“display traffic policy statistics interface GigabitEthernet 2/0/3 inbound”查看端口流量统计信息，在出方向和入方向均为发现数据包存在，如图2所示。接着又在内网交换机2/0/0上（与防火墙互联接口）应用流策略，同样也未发现数据包过来。

据此我们可以判断数据没有到达该交换机上，继续向上级设备查找故障原因，通过在防火墙上查看会话表的信息，发现从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地址，通过排查发现该地址在源NAT中应用了“nat address-group index 0 name 内网地址 10.*.6.115 10.*.6.115”，该命令的意思是从外网访问内网时NAT成内网地址10.*.6.115找了Web界面中的配置，如图3所示。

将图中源地址转换为接口IP地址后业务恢复正常。但是笔者仍有疑问，为什么同样的NAT，业务支撑系统正常呢？

再次返回内网交换机上查看路由发现，在内网交换机上与内网交换机2上起了OSPF，将10.*.6.0 255.255.255.0通过OSPF发布出去了，也就是说在业务支撑系统可以通过OSPF路由学习到10.*.6.115的路由，所以网络可达，但是想访问话务系统10.*.6.12，防火墙只会将源地址NAT成10.*.6.115，而10.*.6.115是防火墙上的一个虚地址，并非接口地址，这样数据就不会再到话务系统了。

图2 接口流量统计

图3 防火墙的源NAT配置

当改成NAT成接口地址后，在防火墙及内网交换机上通过静态路由可以正常到达话务系统。

结语

虽然只是一个小小的配置出了错，但是在排查的过程中却受了不少周折。网络管理是一项全面而细致的工作，需要我们具备必要的理论知识及丰富的经验，排查故障的思路一定要清晰，排查手段更是关键，就像本文中使用的交换机的流量统计，可以帮助我们判断出故障点，免去抓包的繁琐。

虽然网络通了，但是仍存在一定的安全隐患，下一步我们将使用安全性较高的L2TP over IPSec VPN打通内外网。