Libreswan隧道下长SQL查询失效问题求助

1. 调整TCP MSS Clamping（核心修复步骤） #

MTU设为1392后，对应的TCP MSS需同步调整为1392 - 40（IP+TCP头部）= 1352，仅改MTU无法确保TCP层生效：

• 在Libreswan连接配置文件（通常在/etc/ipsec.d/目录下的.conf文件）中添加：

  leftmss=1352
  rightmss=1352
  

  重启ipsec服务：systemctl restart ipsec
• 或者通过iptables强制MSS值，避免隧道内大包无法传输：

  iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1352
  

  保存规则：iptables-save > /etc/sysconfig/iptables，重启iptables服务。

2. 开启Libreswan与SonicWall的碎片处理 #

确保两端允许IPsec报文分段，避免大查询数据包被丢弃：

• 在Libreswan配置中添加：

  fragmentation=yes
  rightfragmentation=yes
  

• 登录目标SonicWall后台，检查并开启IPsec碎片处理选项（部分型号默认关闭）。

3. 调整ODBC与SQL驱动参数 #

• 修改ODBC配置文件（如/etc/odbc.ini），延长超时并适配数据包大小：

  ConnectTimeout=30
  QueryTimeout=60
  PacketSize=8192
  

• 确认SQL Server驱动版本与办公室服务器一致，部分旧版本驱动对大查询的兼容性较差。

4. 优化系统TCP参数 #

编辑/etc/sysctl.conf，添加以下参数优化长连接与大报文传输：

net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_max_segment_size = 1352

执行sysctl -p使配置生效。

5. 抓包定位报文问题 #

用tcpdump抓取隧道接口的SQL查询报文，确认数据包状态：

tcpdump -i ipsec0 host <你的SQL Server IP> and port 1433 -w sql_long_query.pcap

分析pcap文件：如果出现ICMP Destination Unreachable (Fragmentation Needed)，说明MSS仍未正确配置；如果无报文到达SQL Server，需检查隧道路由或防火墙规则。

6. 对齐两端VPN加密配置 #

将云端Libreswan的加密算法、认证方式、PFS组等配置，与办公室SonicWall的VPN参数完全匹配，部分加密套件对大报文的处理效率差异会导致超时。

内容的提问来源于stack exchange，提问作者joseggarza