一次MTU问题导致的RDS访问故障

导语

VPN是一种通过公网连接两个或多个私网站点的专用网络，使得这些站点仿佛是通过专线连接在一起。IPSec是一套协议框架，用于保证数据传输的私密性，完整性，真实性。但是VPN网络经常会带来一些连通性上的问题，通常与MTU设置的不合理有关。本文通过一个实际案例，来具体分析解决这个问题。

1环境拓扑

1. 链路中，各个设备接口的MTU为1450

   MTU是数据链路层的概念，限制的是数据链路层payload的大小，即上层协议大小(包括上层协议头)，例如设置主机接口mtu为1450。则在一个TCP报文中，1450 = 20字节IP头 + 20字节TCP头 + 1410TCP数据。

2. RDS为京东智联云云数据库实例，实例中创建有400个数据库。

3. SH_MariaDB_VM是一台上海地域的云主机，部署了mariadb服务，数据和RDS实例相同。

4. BJ_VPNGW和SH_VPNGW分别是北京VPC和上海VPC的vpn网关

5. bj_client所在子网和RDS所在子网通信时，下一跳为各自所在地域的vpn网关

2现象描述

1. bj_client通过BJ_VPNGW连接RDS。执行show databases时，一直卡住无返回。

2. bj_client通过BJ_VPNGW连接SH_MariaDB_VM。执行show databases正常，没有卡住的现象。
   

3排查过程

1. bj_client可以ping通RDS，telnet RDS 3306端口正常，使用mysql客户端也可以正常连接。

2. 在BJ_VPNGW和SH_VPNGW上抓包分析。发现RDS回包正常到达SH_VPNGW，但是没有到达BJ_VPNGW。数据包在SH_VPNGW被丢弃。怀疑是MTU问题，导致丢包。

3. 继续抓包分析RDS和SH_MariaDB_VM回包的区别。发现SH_VPNGW都给RDS和SH_MariaDB_VM回了一个IMCP Error报文，报文中指定了MTU next hop: 1374 。但是RDS的重传报文中，ip层的Total Length一直是1450。SH_MariaDB_VM在首次被丢包后，重传报文的Total Length为1374。判断ICMP Error报文没有被正常转发给RDS服务端。后核实RDS前面还有一层LB，该LB没有转发ICMP Error。

4. 调整bj_client接口mtu为1374之后，问题解决。

4问题原因

5解决方案

1. 调小服务端或者客户端mtu，让两端在建立三次握手协商mss时，以更小的mss收发数据。可以设置为ping探测的路径MTU值。

2. 在VPN网关配置iptables -t mangle -A FORWARD -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 。两端建立三次握手的报文到达vpn网关时，修改MSS值，使MSS自适应PMTU(Path MTU)

3. 保证icmp error报文可达

6其他