对外映射应用服务器问题处理案例分享

15

前言

随着社会信息化的快速发展，网络中的互联设备趋于复杂化，给网络管理员排除网络故障也带了较大的挑战。网络一旦出现问题，排查起来非常困难，甚至无从下手，难以找到问题根源，如何进行问题定位，一个较好的排查故障的方法对于网络管理员极其重要。

本次简单分享一个网络故障排除法的案例，通过网络故障现象进行初步定位，配合一些有必要的测试工作，然后通过准确抓包分析，再快速定位故障点，最后解决问题。

1

故障描述

2018年x月x日某客户提出需求，需要将新上线的内部服务器10.0.183.10:1521在外部路由器上映射至10.1.67.142:1521，但部署后发现在外部终端10.0.64.50无法访问映射后的服务器应用端口10.1.67.142:1521。

2

处理过程

排除法是一个较好的处理方法，本次便采用排除法来进行网络排障。

现场网络拓扑图

在外单位的终端10.0.64.50的终端上进行测试访问，显示访问失败，但在外单位的终端10.0.79.99上进行访问测试，能够正常访问。下图为外单位终端10.0.64.50测试访问10.1.67.142:1521的结果。

首先排查各网络设备之间网络联通性，各互连网络设备之间能够互ping通。从外部终端10.0.64.50能够ping通10.1.67.142。

为了继续排查问题出在哪，在SW1上面布署一台测试应用服务器10.0.184.11:1521，在对外服务器变更10.1.67.142:1521映射至10.0.184.11:1521，然后在外部终端10.0.64.50去访问10.1.67.142:1521，能够正常访问，说明问题很可能在内部SW1与应用服务器10.0.183.10之间。

决定抓取内部SW2上联内部SW1的物理接口G0/0/1的包，以确定问题出在哪。用外部终端10.0.64.50/10.0.79.99同时访问10.1.67.142:1521，然后抓包发现10.0.64.50访问10.0.183.10:1051有请求包，无回应包；而10.0.79.99访问10.0.183.10:1051既有请求包，又有回应包。

从抓包现象可判定问题很可能出现在内部SW2上面，继续检查内部SW2的路由，在SW2上tracert 10.0.64.50发现下一跳没有跳至内部SW1，继续核对内部SW2的路由表，发现有一条静态路由10.0.64.0/255.255.255.0并没有指向内部SW1。

ip route 10.0.64.0 255.255.255.0 10.0.172.3，而10.0.172.3不是内部SW1与内部SW2互连的IP地址。

新建一条主机路由10.0.64.50/32指向内部SW1,请外部终端10.0.64.50测试访问10.1.67.142:1521，测试访问正常。

3

结论和建议

遇到此类问题，先检查互联网络设备之间的网络联通性，然后使用排除法，一步步缩小范围，确认导致问题所在的设备范围后，用正确的方法进行测试，解决之。

—END—

▼