数据包来回路径不一致造成网络不稳定

■湖北广播电视大学教育技术中心 熊迪

随着近年来高校信息化应用的不断深入，对校园网络的质量要求也日益增加。笔者作为一名高校网络运维人员，在工作中遇到很多网络上的“疑难杂症”。其中“数据包来回路径不一致”就是一个非常典型的校园网络故障，我们对此现象进行了分析和研究，摸索出了一套解决办法。

我们知道TCP/IP 协议中，两台主机要建立网络连接，需要进行“三次握手”。“三次握手”的过程实质上就是来源主机与目的主机之间交互特定TCP 报文的过程。TCP 报文中包含“源地 址”（Source Port）和“目的地址”（Destination Port），分别反映了来往主机的地址及端口信息。建立连接时，主机A（简称A）向服务器B（简称B）发送SYN数据包，该数据包中源地址是A 的IP，目的地址是B 的IP；B 收到SYN 请求，将回复SYN+ACK 数据包，此时源地址是B 的IP，目的地址是A 的IP；A 收到以上数据包后，将发送ACK 确认包，连接成功。

图1 数据包来回路径不一致的典型案例

如果在这个过程中，源地址或者目的地址出现了变化，就会出现“数据包来回路径不一致”，主机之间将无法识别对应的连接，导致网络故障。

我们遇到的一个典型案例，网络结构如图1。服务器B 在防火墙上做了地址映射，其内网地址是10.0.0.13，映射后的互联网公网地址是219.0.0.13，用户A 的PC 内网地址是10.1.1.1，防火墙的内网口地址是10.10.2.2。

用户A 反映：每次在校园网内访问服务器B（219.0.0.13）上的应用，响应速度极慢，多数时候无法正常使用，偶尔能用，询问其他的同事，少数人能正常访问，多数人和他的网络症状类似，奇怪的是当大家通过手机4G 网络或在校外访问服务器B 时一切正常。

图2 数据包来回路径不一致示意图

通过对A、B 之间数据流的分析，我们发现用户A 发出的请求数据包通过网关交换机传递到防火墙，防火墙将目的地址（服务器B的公网IP）进行NAT转换变成服务器B 的内网地址，然后从防火墙的内网口经网关交换机传送到服务器B。此时服务器B 收到的数据报文中“源地址”是10.1.1.1，“目的地址”是10.0.0.13。服务器B产生回应数据包，“源地址”是自身的10.0.0.13，“目的地址”是用户A 的内网地址10.1.1.1。当此数据包到达网关交换机时，交换机发现“目的地址”是直连VLAN 中的IP，于是将直接转发给用户A，而不再经过防火墙。用户A 将收到一个来自10.0.0.13（而非当初的请求地址219.0.0.13）的数据包，它将认为这是一个全新的连接，造成A、B 间通讯异常。如图2 所示，这就是一个典型的“来回路径不一致”造成的故障案例。由于4G 网络用户的IP 在校园网内无法转发，所以未受到影响，访问一切正常。

对于这种情况，市场上有些防火墙或路由设备设置了一些“保护措施”，笔者单位的防火墙设备正是如此。当防火墙发现对服务器B 的请求是来自内网接口（trust域）将触发一条SNAT，将“来源地址”转变成防火墙的内网口地址（即10.10.2.2），再以此为来源访问服务器B。用这种方式保证服务器B 回包时数据流必须回到防火墙，从而回包路径与请求包路径保持一致。

这样一来虽然解决了“来回路径不一致”的问题，但又引发了一个新的问题。经抓包监测，服务器此时接收到大量来自防火墙内网口10.10.2.2 的访问请求。服务器上的网络安全系统将这些请求判定为异常的攻击行为，采取了大量的“丢包”处理。这就是前文中提到的“少量用户可以访问服务器B，其他用户访问速度很慢”的原因。

对此，我们摸索出了两套不同的解决方案：

1.在防火墙（或相应路由设备）上将来源地址进行一次主动的SNAT 处理，将用户A 的IP 地址映射到校园网中“不可达”的某一网段中，迫使回应数据包必须依赖防火墙做转发。同时，由于进行了主动的SNAT，所以即便访问申请来自内网口，防火墙也不会触发默认的地址转换策略，避免出现统一访问来源的现象。

2.如果是通过域名访问服务器B，则在校内的DNS 服务器上进行域名劫持设置，直接将域名解析成服务器的内网地址，这样校内用户对服务器B 的访问数据流只在校园网内（即网关交换机以下）流转，相对安全且高效。

至此，问题得以解决。总结下来，网络数据在传输过程中可能遇到各式各样的问题，运维人员只有掌握原理，仔细分析才能找到有效的解决办法。