客户描述的网络故障：更换路由器和交换机后，在内网无法使用oa.xxx.com:8086来登录OA系统了。

开始排查前的测试：我不在客户内网，于是在外网使用oa.xxx.com:8086尝试登录OA系统，成功。

测试结果说明：1、外网域名解析正确；2、路由器端口映射正确。

先来温习一下相关知识点，以便于更好地阅读本文以下内容：

知识点1：在标准的网络架构中，外网用户通过域名:端口号来访问服务器，需要在出品网关设备上配置端口映射(有些设备直接统称为NAT)，然后在外网的域名管理后台配置好解析就可以了；

至于内网用户，那就在内网的DNS服务器上写一条A记录，指向服务器IP好了，如下图所示：

这样一来，用户无论是在内网还是在外网，都能通过过统一的域名:端口号的形式访问服务器。

知识点2：在多年的IT外包服务过程中发现，很多单位都没有域控，也没有DNS服务器，而是直接使用运营商的DNS服务器来解析上网；而且，有些程序员把IP写在了程序里面，导致内网用户只能用外网IP来访问明明放在内网的服务器，那就需要在出口网关设备上配置一个特殊的NAT

举例（1）：TP-LINK路由器

如上图所示，配置端口映射的时候，把环回地址192.168.1.0/24填上，表示整个网段的电脑，在内网都能通过公网的IP地址和端口登录金蝶ERP服务器(192.168.1.163)，当然在外网就更不用说了。

举例（2）：华为防火墙

如上图所示，华为防火墙上需要配置一条特殊的NAT策略：NAT转换模式是“仅转换源地址”；源安全区域，毫无疑问，肯定是trust；源地址，跟TP-LINK一样，也是填写192.168.1.0/24，表示整个网段；目的地址，这里是192.168.1.8，这个客户也是金蝶ERP，只是内网IP地址不同而已，这个无所谓；关键的点在最后，源地址转换为“出接口地址”，意思是把内网192.168.1.0/24访问服务器的数据流，转发WAN口去，也就实现了在内网能通过公网的IP地址和端口访问登录金蝶ERP服务器。

当然了，由于防火墙的特殊之处，我们还需要配置一条安全策略，允许trust和untrust区域访问这台金蝶ERP服务器。

我想象的解决方案

其实经过简单快速的测试后，我心里很快就制定了解决方案：

1、路由器上配置特殊NAT，使内网用户能使用外网的IP和端口号来访问内网的OA服务器。这种情况是因为内网没有DNS服务器，客户端都直接采用运营商的DNS服务器，所以oa.xxx.com域名解析出来的IP，是外网IP；

无论是什么品牌的路由器，总之殊途同归，配置方法大同小异。

2、更新内网DNS服务器上的A记录。这种情况适用于内网有DNS服务器，可能是更换交换机、路由器后，网段或者IP发生了变化，路由器虽然做了正确的端口映射，但是没有及时更新DNS记录。

解决方案制定了，钱也收了，开始干活。

但，实际上的解决步骤，完全没那么简单，而是像极了“捉妖记”

第一步、尝试在路由器上配置特殊NAT

通过远程软件，登录客户的笔记本电脑，登录路由器，是台锐捷RSR30-X-SPU10，我记得原来是台烽火路由器，看运行时间，这才1天，说明是新换上的路由器。

直捣黄龙，打算一击毙命——直接点击NAT菜单，看了端口映射，每一条后面都加上了permit-inside，呃……既然这样，为什么内网用户不能访问OA？

Ping oa.xxx.com，能通啊，没毛病，显示IP为192.168.2.163。

打开浏览器，输入oa.xxx.com:8086，确实打不开登录页面；

浏览器的地址栏中改为输入刚才ping得到的IP，即192.168.2.163:8086，还是打不开登录页面？！

不应该啊，外网都能打开，表示端口映射正确，内网服务器正确响应，凭什么在内网用内部IP和端口号都无法登录？

回到端口映射的地方，仔细一看，嚯，外网的8086端口，对应的是192.168.2.63，并不是Ping oa.xxx.com得到的192.168.2.163。

看来问题就出在这里！

第二步、尝试更新内网DNS服务器上的A记录

经询问得知，客户内网没有DNS服务器，在路由器上、在客户的电脑上，也都得到了印证，确实都是直接设置的运营商DNS服务器。

但，运营商不可能给客户配置一条内网IP的解析记录，那这条错误的DNS记录是从何而来？

举个例子，如果是爱快的路由器，在网络设置菜单，进入dns设置，DNS加速开启后，会多个反向代理的功能，然后就可以添加内网的解析记录了，如下图所示：

但是，我翻遍了这台锐捷路由器，没有配置DNS代理，也没有看到有这条错误的DNS记录，那我又该从何改起呢？

好了，到此，我脑海里快速制定的解决方案，算是正式泡汤了。

第三步、尝试在交换机上修改静态域名解析

除了路由器之外，交换机上也可以配置静态的DNS域名解析，下面以H3C交换机为例说明，只要以下一条命令就行了：

Ip host oa.xxx.com192.168.2.63

然后在交换机上，直接ping oa.xxx.com，192.168.2.63这台服务器就会有响应了。

顺便提一嘴：这条命令，同样也能适用于H3C的路由器。

可是，问题又来了，客户反馈说，现在用的是傻瓜交换机，新的交换机，运营商还没换上呢。所以，没办法配置域名解析，也就是说，当前错误的DNS记录显然也不是来自交换机。

怎么会这样？此时脑海里响起一句话：“不可能，绝对不可能！”

可是现实就摆在眼前，真是活见鬼了，内网到底是什么妖怪在兴风作浪啊？

第四步、难道是HOSTS文件在作妖？

难道是192.168.2.163这台服务器的计算机名称设置成了oa.xxx.com ?

想用远程桌面登录这台服务器，失败了，想来是没开远程桌面。

于是用ping -a192.168.2.163，要求解析IP地址的主机名，结果显然不是oa.xxx.com，可是，现在ping oa.xxx.com，返回的IP就是192.168.2.163，但是事实上， 它就应该是192.168.2.63，感觉陷入了僵局，去哪儿说理啊。

路由器上没配置，交换机是傻瓜交换机，没有域控，没有DNS服务器，这条鬼魅般存在的错误的DNS记录，究竟从何而来？

头有点晕，难道是HOSTS文件在作妖？

以管理员打开记事本，然后打开C:\Windows\System32\drivers\etc 目录下面的HOSTS文件，发现并没有oa.xxx.com这条记录。

没有也好，我给它加上吧，就写在最后一行：192.168.2.63 oa.xxx.com，点保存立即生效，不用重启什么。

Ping oa.xxx.com，这次终于返回了正确的IP：192.168.2.63，浏览器打开oa.xxx.com:8086，成功地打开了OA系统的登录页面。

把这个文件分发下去，给所有同事覆盖一下？

10秒钟以内，我就否决了这个想法，笔记本用户搬到外网怎么办？难道做个批处理，每次点击一下来修改这个HOSTS文件吗？那不行，太麻烦了，别说客户接受不了，连我自己都过不了这一关，果然放弃。

第五步、期待运营商解决

不是还要更新交换机嘛，赶紧通知运营商把新的交换机换上，然后不就能利用交换机来写内网的静态域名解析了。

但是，高兴不过一分钟，打击又来了——虽说新的交换机已经到了，运营商马上就可以换，可是，并没有网管交换机，只是傻瓜换傻瓜而已，计划又一次泡汤了。

此时，运营商的另外一名工程师也表示不解，上线远程另外一台电脑，也是各种检查和测试，nslookup时，运营商的DNS服务器，竟然也返回了192.168.2.163这个错误的记录，关键是，它居然返回一个内网的IP，真是活见鬼！

此时他也连呼：“不可能，绝对不可能！”

可我也在线，全程看着他操作，最终，他也是打开了HOSTS文件，我赶紧提醒，别浪费时间了，HOSTS文件没写什么，但是只要写上，就立即能正确解析。

然后，他也放弃了，约定第二天重新换一台路由器。

很好，幸亏我有绿联氮化镓充电器，否则 我的笔记本电脑和手机都要没电了。

第六步、峰回路转、豁然开朗，这次终于“捉妖”成功

第二天下午，运营商拿了台同型号的路由器，上线，配置，测试，结果，还是一样，错误的DNS记录还是阴魂不散地存在着。

我有些倦了，走到台盆前洗了把脸，对着镜子里的自己说：

Tel me why? 总共就那么几个设备，到底哪个还跟错误的DNS记录有关？

答案很显然：只有路由器，只能是路由器！

可是，路由器菜单都翻烂了，也没找到DNS相关配置啊，只是填写了一个运营商的DNS服务器IP，能有什么影响呢？

到底哪一项的设置，还跟这个错误的DNS记录有关？

等一下，DNS？脑袋里突然灵光一闪，那会不会是跟DNS ALG功能有关？

现在的情况是：内网多台服务器上存在着不同的服务，也就是在同一个公网IP上映射了许多不同的端口，使外网用户能通过这些不同的端口，访问到不同的服务器提供的服务。

这样的场景下，如果路由器开启了DNS ALG功能，就会有个问题：DNS ALG只会根据IP地址进行转换，无法区分不同端口对应着不同的内网服务器。

虽说使用运营商的DNS服务器进行域名解析，理论上应该会解析为外网IP，但由于路由器上的DNS ALG功能，所以oa.xxx.com，可能直接被路由器定义为排在第一条端口映射的服务器上，也就是错误地定位成了192.168.2.163，从而无法正常打开OA登录页面。

虽然我翻烂了路由器的菜单，但是，DNS ALG功能并没有显示在WEB配置页面上，好吧，那就尝试命令行关闭DNS ALG功能吧，在全局模式下，输入以下命令：

no ip nat translation dns

然后，给客户的笔记本电脑恢复HOSTS文件，再次打开浏览器，输入oa.xxx.com:8086，终于成功地打开了OA系统的登录页面！

问题解决了，修改路由器默认的账号密码，并且保存路由器配置，收工。