面考虑了，笔者准备在子公司路由器上做设置，通过NAT实现数据转发，同时将XX.XX.91.120这个地址以NAT SERVER的方式对外宣告出去，这样理论上讲数据包就能够顺利到达XX.XX.91.120了，毕竟经过宣告只要数据可以到达路由器外网接口就能够顺利转发到内网相关NAT SERVER中。笔者使用nat server global XX.XX.91.120 any inside XX.XX.91.120 any ip命令完成宣告服务的任务。（如图6）

   

    
    同时利用nat outbound 2001 interface命令在外网接口上开启NAT服务，保证nat server的顺利宣告。（如图7）
    
   

    
    然而通过宣告NAT SERVER后问题依旧，至此笔者就再也不怀疑路由器相关路由表问题了。接下来冷静分析发现只要在外网PING XX.XX.91.120都是不通的，而在内网或出口路由器上PING XX.XX.91.120却没有任何问题。笔者继续尝试其他主机的连通性，发现除了XX.XX.91.120有这个问题外，其他IP地址都不存在无法PING通的问题。看来故障的根源再于这台主机。经过排查发现这台安装了PANABIT流量管控程序的freebsd系统自身网络设置存在问题，没有设置网关地址为XX.XX.91.126，使用ifconfig命令添加完毕后故障解决。
   

上一页  [1] [2] [3] [4] 下一页

    四，总结：
    实际上在本次路由故障解决的全过程中笔者走了一些弯路，首先由于我是上级网络管理者，所以无法对该子公司内网计算机的设置状况有一个清晰的了解，在出现PING不通无法访问的问题时也没有及时的通过PING其他主机是否畅通来判断是网络问题还是主机问题，因为我自己无法判断到底该子公司哪台机器处于开机状态可以PING通；另外笔者在进行tracert XX.XX.91.120时在第18跳时发现了request timed out的错误提示，这点迷惑了我，认为是网络问题，路由问题。而后来的结果证实了这个推断的错误性，看来以后在进行网络维护时Tracert的结果并不能太过分相信，本例中应该再执行tracert XX.XX.91.120后再执行tracert XX.XX.91.126来判断他们在tracert路径上是否存在差异来快速定位故障。希望本人的这些经验可以帮助更多的IT168读者。

 

 

上一页  [1] [2] [3] [4]