这几天操作GNS3和VMWare的实验环境，总是会出现一些神奇的未知的错误。而这些错误经过排错后仍然无法解决，后来重新配置环境等一系列尝试后能够达到理想的状态。这里就来简单说一下这些非常规情况下的解决方法。
先来说常规思路，一个网络不通畅，则需要考虑的点有以下：
1.连线与接口是否匹配
2.每个端口的IP地址、子网掩码、网关是否正确
3.路由器是否配置时钟频率和静态/动态路由
4.链路测试
*5.特殊情况
*6.NAT特殊性
指导思想：逐层排错，链路测试。
1.连线与接口是否匹配
这是最基础的，广域网用串口线；局域网用直连线。可以通过GNS3中的文本显示来更清楚的掌握每个端口的ID。广域网是路由器之间的网络，局域网是接交换机的网络。
图中的按钮能显示端口等一些细节的名称。
2.检查端口的IP、子网掩码、网关。特别要考虑NAT模式的特殊性。
这一般是最容易忽略的点，尤其是网关，考虑到VMWare中NAT模式的特性，默认使用NAT服务的网关，而这个网关如果与实验中设定的网关不同，仍然会走默认路线，而又因为虚拟机与物理机连接，可以通过NAT的网关走物理机并访问另一台虚拟机，而不是使用我们搭配的网络环境。
如上图，80网段的网关设置的是80.5，但是我的NAT模式网关是80.10。那么我发现了一个神奇的问题：10网段ping VMnet8下的虚拟机，不通；但是VMnet8下的虚拟机可以ping通VMnet1下的虚拟机。这就非常奇怪，因为数据包有来有回才能通，既然双向可达，为何会出现这种情况呢？
我使用tracert命令发现了问题。
我发现VMnet8网卡直接使用默认的NAT端口出去并转发到了目的地，因为NAT端口可以到达物理机，而物理机又与众多虚拟机直连。所以这种情况下，我修改了网关，指定为80.5的网关。
然后再跟踪VMnet1.
得到了理想的结果，而且也因此VMnet1 能够ping通 VMnet8。至于为什么，我们来抓包看结果，抓VMnet1和GNS3交换机的连线。
我们可以看到，当VMnet8 PING VMnet1时，VMnet1抓到的包是这样的，数据包来自于10.1，而10.1是物理机直连虚拟机的网卡！！（为了简化以后VMnet简称V）
V1收到来自物理机发来的数据包，这个数据包是由V8先发到物理机而发到虚拟机的，也就说根本没有走规定的网络。
然后我们来看一下 V1 PING V8
这次为了确定数据流向，我在4条链路上抓包。发现最后一条路有reply数据包，而其他链路没有reply。
我们发现，数据包单向可到达V8，但是V8的数据包却在返回时丢失了，甚至还没有到达第一个路由，是因为V8默认网关80.10，而回传的数据包因为是响应数据包，为了在网络中传输，数据链路层协议里附加了MAC地址信息，而返回的数据包走了网关80.10，在那个网关下的接口没有对应的目标MAC地址，所以数据包丢包了。
所以，这就解释了为什么V8可以ping通V1虚拟机，而V1却ping不同V1虚拟机。V8的数据包到达V1后，V1返回数据包会按照我们搭建好的网络顺利到达V8。
说到底，这都是网关的问题，而NAT模式是最容易出问题的网关。
3.路由器是否配置时钟频率和静态/动态路由。
这个反而好理解了，用show ip route命令就可以看到静态路由和动态路由，只要确认有没有和下一跳路径对不对即可。而时钟频率比较容易忽略，一定要配置时钟频率，时钟频率在DCE端口配置，且数值有一定要求，不能随便配置。
4.链路测试
所谓链路测试，也就是检测全网畅通与否，检测网络畅通方法之一是一条路径上所有节点间连线都进行抓包，然后根据链路上是否有去有回来判断数据包网络连通性。也可以一条路径一条路径进行ping测试，然后确认一下哪条路径不对劲，对端口进行上面的一些检查。
5.特殊情况：上面的情况检查完后，理应没有问题的情况下，此时就属于不是理论上错误的特殊情况了，这种特殊情况出现的原因不确定因此不好解决。通常都是以尝试的方式来纠错，包括断开连线重连、重启应用程序、重启电脑、重新配置一个完全相同的环境等。
还有，每次开机运行久了，偶尔会出现物理机上VMnet网卡失效的情况，比如WIN+R来访问网上邻居，发现连不通，此时禁用并重新启用网卡就会解决。
还有Cloud 加新网卡并接入路由器时报错，这种情况是因为GNS3在安装时会绑定电脑上的网卡，卸载重装GNS3即可解决。
总而言之，出现很多理论上没有错而测试结果就是不对的情况，可以考虑重新配置环境。往往比i想象的要有效。
6.NAT 特殊性
仍然是这个例子。我们画成拓扑图方便理解
我们来详细分析一下，为什么在默认网关指向80.10时（NAT服务）会出现PC2ping通PC而PCping不通PC2。
首先，我们先看正常情况下，网关指向80.5（配置的网关）
这时很好理解，就是按照我们配置的走，也是最简单的路径。而我们知道，NAT模式下的虚拟机非手动指定，会走默认网关（80.10）。
此时却出现了神奇现象：PC2pingPC通而PCpingPC2不通。
我们通过抓包发现：
数据的来源不是80.129而是80.1，也就说NAT对其进行了地址转换，那么在这种情况下，就会出现问题了。
下面的情况：
PC2pingPC
1.PC2的数据包到达NAT路由，做地址转换，准备上因特网；此时地址已经变更为与物理网卡的地址1.113；然后发现可以通过直连网卡80.1来发送数据包，此时做第二次地址转换，地址变为80.1；然后PC收到数据包。此时PC2收到数据包后再返回数据包，此时，对这个数据包而言，1.113是内网，10.1是外网，他们通过地址转换得来；80.10是1.113的内网，也就说是内网中的内网。但是因为NAT服务的存在，所以原路返回是可能的。
PC ping PC2
2.PC的数据包根据规定路线到达PC2，PC2返回数据包，走NAT（默认网关）。NAT会转换两次地址，一次转化为物理网卡，再一次转换为虚拟网卡VMnet8，每次转换都对PC而言是内网。当PC2收到反馈的数据包后，就会发现一个问题，我ping的是192.168.80.129，为什么从80.1返回一个数据包，我并没有对你进行请求，这是一个风险数据包就丢包了。这样就会导致PC ping PC2不通。
综上所述，对于虚拟机环境的排错。NAT服务下的计算机会出现很多需要额外注意的点，如果想要避免这些问题，那么实验过程中尽可能使用两个仅主机模式的虚拟机而不使用NAT模式的虚拟机。但是，这种排错的思想理念，通过抓包分析数据包的流向，都是非常重要的学习过程，而且，每当搞明白一个问题，对一个服务或系统的理解都会更进一步。