关于IPSec 虚拟私有云网络连接异常的处理

​一、问题描述现场使用云能的融合网络产品与异地机房的设备建立IPSec tun实现内网是连通它是一款基于Internet通过加密通道实现本地数据中心或客户端入云访问VPC资源和不同地域VPC之间互联能力的服务。支持IPsec、SSL和Smart方式现场使用其中的第一个​​​​二、产品简介和特性IPsec方式是基于Internet的加密tun实现TUN的端到端加密可确保数据传输在安全性传输费用相较专线服务更为低廉。安全控制方面可通过配置指定访问VPC内的网段实现数据访问控制细化管理。1、该融合网络产品支持行业标准的SSL协议和IPSec/IKE协议支持多种加密算法。2、支持通过客户端SSL、Smart类型和本地数据中心IPSec类型入云访问云上VPC的资源。3、支持不同地域的VPC之间通过Internet快速建立加密通道实现VPC互通IPSec方式。4、支持客户端SSL、Smart类型和本地数据中心IPSec 方式的接入数在配额范围内按需调整灵活伸缩调整。​​2.1、IPsec的3个重要协议- IKE/AH/ESPIKEInternet Key Exchange因特网密钥交换IKE协议是一种基于UDP的应用层协议它主要用于SA协商和密钥管理。IKE协议分IKEv1和IKEv2两个版本IKEv2与IKEv1相比修复了多处公认的密码学方面的安全漏洞提高了安全性能同时简化了安全联盟的协商过程提高了协商效率。/IKE协议属于一种混合型协议它综合了ISAKMPInternet Security Association and Key Management Protocol、Oakley协议和SKEME协议这三个协议。其中ISAKMP定义了IKE SA的建立过程Oakley和SKEME协议的核心是DHDiffie-Hellman算法主要用于在Internet上安全地分发密钥、验证身份以保证数据传输的安全性。IKE SA和IPsec SA需要的加密密钥和验证密钥都是通过DH算法生成的它还支持密钥动态刷新。/AHAuthentication Header认证头​AH协议用来对IP报文进行数据源认证和完整性校验即用来保证传输的IP报文的来源可信和数据不被篡改但它并不提供加密功能。AH协议在每个数据包的标准IP报文头后面添加一个AH报文头AH协议对报文的完整性校验的范围是整个IP报文。/ESPEncapsulating Security Payload封装安全载荷ESP协议除了对IP报文进行数据源认证和完整性校验以外还能对数据进行加密。ESP协议在每一个数据包的标准IP报头后方添加一个ESP报文头并在数据包后方追加一个ESP尾ESP Trailer和ESP Auth data。ESP协议在传输模式下的数据完整性校验范围不包括IP头因此它不能保证IP报文头不被篡改。AH和ESP可以单独使用也可以同时使用。AH和ESP同时使用时报文会先进行ESP封装再进行AH封装IPsec解封装时先进行AH解封装再进行ESP解封装。2.2、IPSec的两种封装模式传输Transport模式和Tunnel模式1传输模式​2TUN模式对比发现传输模式和TUN模式的区别如下传输模式在AH、ESP处理前后IP头部保持不变主要用于End-to-End的应用场景。TUN模式则在AH、ESP处理之后再封装了一个外网IP头主要用于Site-to-Site的应用场景。2.3、四次挥手过程上图中MSL被认为是一个发送的时间那么2MSL就被认为是一个发送和回复所需的最大时间如果直到2MSLClient仍然没有再次FIN那么Client推断ACK已经成功被Server端接收则结束TCP连接。如果Client的ACK在回复过程中丢失的话理论上Server端需要重新发送FIN报文以便于正常结束连接。cat /proc/sys/net/ipv4/tcp_fin_timeout单位是秒这个值是2MSL的时间三、问题处理1、现场抓包tcpdump-ibond0-vvhost172.16.4.2 and port7480#windows抓包netsh trace startcaptureyestracefilec:\temp\7480.cap#或netsh trace startcaptureyesproviderMicrosoft-Windows-TCPIPlevel5tracefilec:\tcp7480.etl# 30 秒后netsh trace stop#导入wireshark查看分析过滤 tcp.port748017:08:33.781038 IP(tos 0x2,ECT(0), ttl124,id19924, offset0, flags[DF], proto TCP(6), length52)172.16.4.2.5905node1.7480: Flags[SEW],cksum0x6e51(correct),seq6708622, win64240, options[mss1382,nop,wscale8,nop,nop,sackOK], length017:08:33.781100 IP(tos 0x0, ttl64,id0, offset0, flags[DF], proto TCP(6), length52)node1.7480172.16.4.2.5905: Flags[S.],cksum0x7345(incorrect -0xe3c0),seq2758600325, ack6708623, win64240, options[mss1460,nop,nop,sackOK,nop,wscale7], length017:08:33.791935 IP(tos 0x0, ttl124,id19926, offset0, flags[DF], proto TCP(6), length40)172.16.4.2.5905node1.7480: Flags[.],cksum0x1b83(correct),seq1, ack1, win1025, length017:08:33.792571 IP(tos 0x0, ttl124,id19927, offset0, flags[DF], proto TCP(6), length252)172.16.4.2.5905node1.7480: Flags[P.],cksum0x2f06(correct),seq1:213, ack1, win1025, length21217:08:33.792593 IP(tos 0x0, ttl64,id54741, offset0, flags[DF], proto TCP(6), length40)node1.7480172.16.4.2.5905: Flags[.],cksum0x7339(incorrect -0x1cbb),seq1, ack213, win501, length017:08:33.794262 IP(tos 0x0, ttl64,id54742, offset0, flags[DF], proto TCP(6), length254)node1.7480172.16.4.2.5905: Flags[P.],cksum0x740f(incorrect -0xc273),seq1:215, ack213, win501, length21417:08:33.794409 IP(tos 0x0, ttl64,id54743, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:08:33.846416 IP(tos 0x0, ttl124,id19930, offset0, flags[DF], proto TCP(6), length40)172.16.4.2.5905node1.7480: Flags[.],cksum0x19da(correct),seq213, ack215, win1024, length017:08:33.846442 IP(tos 0x0, ttl64,id54744, offset0, flags[DF], proto TCP(6), length484)node1.7480172.16.4.2.5905: Flags[P.],cksum0x74f5(incorrect -0xc370),seq1597:2041, ack213, win501, length44417:08:33.856116 IP(tos 0x0, ttl124,id19932, offset0, flags[DF], proto TCP(6), length52)172.16.4.2.5905node1.7480: Flags[.],cksum0xbfa7(correct),seq213, ack215, win1024, options[nop,nop,sack1{1597:2041}], length017:08:33.856135 IP(tos 0x0, ttl64,id54745, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:08:34.080817 IP(tos 0x0, ttl64,id54746, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:08:34.530810 IP(tos 0x0, ttl64,id54747, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:08:35.420834 IP(tos 0x0, ttl64,id54748, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:08:37.260827 IP(tos 0x0, ttl64,id54749, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:08:40.860838 IP(tos 0x0, ttl64,id54750, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:08:48.060834 IP(tos 0x0, ttl64,id54751, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:09:02.780830 IP(tos 0x0, ttl64,id54752, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:09:31.590816 IP(tos 0x0, ttl64,id54753, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:10:30.460817 IP(tos 0x0, ttl64,id54754, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length138217:12:28.230824 IP(tos 0x0, ttl64,id54755, offset0, flags[DF], proto TCP(6), length1422)node1.7480172.16.4.2.5905: Flags[.],cksum0x789f(incorrect -0x8812),seq215:1597, ack213, win501, length1382上述抓包发现同一 TCP 会话node1:7480 ↔ 172.16.4.2:5905 出现 连续 多次重传seq 215:1597, Len1382且 对端 ACK 始终停在 213说明 1382 字节大块未被确认对端应用层未读 / 未接收到/接收缓冲区满 / 网卡丢包。而P数据报的DFDon’t Fragment不分段标志该数据报禁止在传输过程中被分片。‌本次抓包交互中TCP窗口中S/SYN/ACK 正常窗口 501 → 1024 正常无 FIN/RST → 连接未断开。重传对象固定始终是 同一 seq 215:1597 → 应用层未读走该 1382 B 块Linux 默认 15 次重传约 900 s才会 RST其中当IP数据报的DF1且其大小超过下一跳网络链路的MTU最大传输单元路由器会‌丢弃该数据报‌由于DF1禁止分片路由器无法将数据报分割成更小的片段以适应链路MTU因此必须丢弃该数据包。建设中间设备MTU较小且DF1即不允许分片那么当源设备走到中间设备时中间设备就会会丢弃该报文然后应答给源端一个ICMP消息Fragment Needed But DF Set。注不管MTU设置为多少以太网头帧尾大小是固定的都是14 4假设MTU设置为65535在100Mbps的带宽中假设中间没有损耗以下是发送这一帧需要的时间的计算公式大概需要5ms即这5ms其他进程发送不了任何数据( 65553 * 8 ) / ( 100 * 1024 * 1024 ) ≈ 0.005(s)这样我们可得到计算公式( T - 14 - 4 ) / T当T趋于无穷大的时候效率接近100%也就是MTU的值越大传输效率最高但是基于上一点传输时间的问题来个折中的选择既然头加尾是18那就凑个整来个1500总大小就是1518传输效率1500 / 1518 98.8%那么100Mbps传输时间(1518*8)/(100*1024*1024)*10000.11(ms)2、ping测试ping-c100-s1382172.16.4.2#ping 1382 B 与抓包长度一致mtr-r-c100-s1382172.16.4.2#mtr 逐跳测延迟/丢包HOST: node1 Loss% Snt Last Avg Best Wrst StDev1.|-- ???100.01000.00.00.00.00.02.|-- ???100.01000.00.00.00.00.03.|-- ???100.01000.00.00.00.00.04.|--172.16.4.10.0%10010.710.810.419.11.05.|--172.16.4.20.0%10010.510.510.411.60.2结论现场ping通正常即说明可基本排除二层交换机硬件故障mtr测试中末跳 172.16.4.2 RTT 稳定 10.5 ms、0% 丢包 表明ICMP 大帧可达丢包出现在 上游段4.2 本机的上联即TUN侧上述结果表明网络层ICMP含 MTU 1500正常与之前 TCP 7480 端口大帧重传现象 不在同一条路径特征故本次丢包/限速 仅针对 TCP:7480 或 1380 B 的 TCP 载荷非 IP 层故障。3、windows防火墙和网口检查Get-NetFirewallRule|Where-Object{$_.Direction-eqInbound}|Get-NetFirewallPortFilter|Where-Object{$_.LocalPort-eq7480}#关闭防火墙Set-NetFirewallProfile-All-EnabledFalse#恢复防火墙Set-NetFirewallProfile-All-EnabledTrue#RSC接收端缩放和 LSO大型发送卸载接收端侧 RSC/LSO Large Send Offload 会导致重组失败PS C:\WINDOWS\system32Get-NetAdapterLso# 相关经验表明Windows 2022 内网网卡开启 LSO 后 1 KB 包被丢弃关闭即恢复。Name Version V1IPv4Enabled IPv4Enabled IPv6Enabled ---- ------- ------------- ----------- ----------- 以太网5LSO Version2False True True 以太网实例0LSO Version2False True True PS C:\WINDOWS\system32Get-NetAdapterRsc Name IPv4Enabled IPv6Enabled IPv4Operational IPv6Operational IPv4FailureReason IPv6FailureReason State State ---- ----------- ----------- --------------- --------------- ----------------- ----------------- 以太网5True True False False NDISCompatibility NDISCompatibility 以太网实例0True True False False NDISCompatibility NDISCompatibility PS C:\WINDOWS\system32Disable-NetAdapterLso-Name以太网实例 0-IPv4#临时禁用PS C:\WINDOWS\system32Get-NetAdapterLso#验证Name Version V1IPv4Enabled IPv4Enabled IPv6Enabled ---- ------- ------------- ----------- ----------- 以太网5LSO Version2False True True 以太网实例0LSO Version2False False True#接收缓冲区 / 窗口缩放若 Disabled建议恢复 Normal后尝试PS C:\WINDOWS\system32Get-NetTCPSetting|Select#现场未启用SettingName ReceiveWindowAutoTuningLevel ----------- ---------------------------- Automatic InternetCustom DatacenterCustom Compat Datacenter Internet PS C:\WINDOWS\system32Set-NetTCPSetting-SettingNameInternetCustom-ReceiveWindowAutoTuningLevelNormalSettingName,ReceiveWindowAutoTuningLevel#查看阻拦的端口PS C:\WINDOWS\system32Get-NetFirewallRule-ActionBlock|Get-NetFirewallPortFilter结论现场未针对特定端口丢弃数据其中‌RSC接收端缩放‌允许 NIC网络接口卡将接收到的数据包分组合并以减少主机需要处理的报头数量从而降低 CPU 负载。‌12 在 Windows Server 中RSC 通常与 RSS接收端扩展协同工作以更高效地分散网络流量到多核处理器。‌LSO大型发送卸载‌允许应用程序将大数据块传递给 NIC然后 NIC 将这些数据分解成适合网络 MTU最大传输单元的数据包减少 CPU 在分片上的开销。‌现场禁用LSO未见效。4、MTU检查ping-c100-s1472-Mdo172.16.4.2# 14728201500#上述1中抓包结果显示DF1 且丢包路径 MTU 1500检查是否set mtu 1500 或 允许分片#测试验证forszin14501400135013001250;doping-c10-s$sz-Mdo172.16.4.2|grep-Etransmitted|packet lossdone10packets transmitted,0received,100% packet loss,time9338ms10packets transmitted,0received,100% packet loss,time9366ms10packets transmitted,10received,0% packet loss,time9012ms10packets transmitted,10received,0% packet loss,time9014ms10packets transmitted,10received,0% packet loss,time9015ms上面说明IP报文的大小是根据MTU决定的MTU其实是由双方决定的假设在传输的过程中有一些网络设备不支持对应的MTU那么这些设备就需要对IP报文进行分片到达目的地后由目的地节点重组。一般不建议IP分片IP分片后如果在传输过程中丢失分片的话需要重传所有的数据。现场后查看产品侧发现在使用IPsec协议建立VPN连接时需注意其仅具备传输已拆分报文的能力不参与数据包的分段处理或重组操作。由于IPsec协议会对原始数据执行加密及封装操作该过程可能导致报文体积增加超过1500。若加密后的报文长度超出网络路径中的最大传输单元MTUMaximum Transmission Unit则可能引发报文丢弃或传输异常。假设路径MTU为1500字节设置的本地网关设备公网接口的MTU也为1500字节则用户MTU的最大值min{1500,1500}-1061500-1061394字节即客户端发送数据包时数据包的大小建议不超过1394字节否则可能会导致数据包无法正常传输。#修改MTUiplinkseteth0 mtu1378#传输侧修改这样立即不再 DF1 丢包TCP 1382 B 帧 自动分片重传消失#windows修改TUN双向一致避免 P MTU Discovery 黑洞Set-NetIPInterface-InterfaceAlias以太网实例 0-NlMtu1378#验证ping-c100-s1350-Mdo172.16.4.2# 0% 丢包nc-v172.16.4.27480/dev/zero# TCP 不再重传PS C:\WINDOWS\system32Get-NetIPInterface|Select InterfaceAlias,NlMtu,ifIndex,AddressFamily InterfaceAlias NlMtu ifIndex AddressFamily -------------- ----- ------- ------------- 以太网5150017IPv6 以太网实例013789IPv6 Loopback Pseudo-Interface142949672951IPv6 以太网5150017IPv4 以太网实例013789IPv4 Loopback Pseudo-Interface142949672951IPv4综上本次问题是因为TUN MTU都是1500路径存在 MTU1500 设备防火墙/TUN/VPN 报文 1382 B 路径 MTU 且 DF1 被强制丢弃。按上述修改源目标MTU执行分片发送后现场对象存储客户端读取桶列表恢复正常。最后应把mtu 1378 写入/etc/netplan/xxx.yaml 或 Windows 网卡高级属性防止重启回退。这里只写windows的ncpa.cpl命令后“Internet 协议版本 4 (TCP/IPv4)” → 点 “属性”—“高级”按钮—“IP 设置” 选项卡 最下方 “接口跃点数” 区域里勾选 “手动指定跃点数”同时在 “MTU” 框里输入 1378。172.16.4.2.13707node1.7480: Flags[.],cksum0xc843(correct),seq8421246:8422584, ack1, win1021, length133812:52:40.472947 IP(tos 0x0, ttl64,id31294, offset0, flags[DF], proto TCP(6), length40)node1.7480172.16.4.2.13707: Flags[.],cksum0x7339(incorrect -0xc8f6),seq1, ack8422584, win24576, length012:52:40.472991 IP(tos 0x0, ttl124,id60538, offset0, flags[DF], proto TCP(6), length1378)172.16.4.2.13707node1.7480: Flags[.],cksum0xc4cc(correct),seq8422584:8423922, ack1, win1021, length13385、IPsec SA 无法完成协商、提示 ESP 算法不匹配对此我们要知道IPsec 协商分两段IKE SA 协商密钥交换、身份认证、策略匹配ESP SA 协商加密 / 认证算法、封装模式、生命周期、PFS你这个报错 SA 无法完成协商、ESP 算法可能存在问题90% 是两端 ESP 加密 / 摘要算法、封装模式、PFS、生命周期、TUN / 传输模式 不匹配其次是 ACL 保护流、端口、防火墙拦截。可按如下排查1ESP 加密算法 / 认证算法 两端不一致最常见加密AES-128/AES-192/AES-256、3DES、SM4 两边不一样认证SHA1/SHA256/SHA384/MD5 两边不统一一端支持国标 SM4一端只支持 AES或一端只支持 SHA256另一端用 SHA12IKE 算法 不匹配IKE 第一阶段加密 / 哈希 / DH 组 不一致导致第一阶段 ok 但第二阶段 ESP 起不来。3PFS Perfect Forward Secrecy完全前向保密 配置不一致一端开启 PFS、指定 DH 组另一端关闭 PFS或两边 PFS DH 组modp1024/modp2048/ecp不匹配必卡死第二阶段SA协商4感兴趣流ACL 保护网段不匹配两端加密保护的本端网段、对端网段子网掩码、网段范围不一致第二阶段策略校验失败SA 无法建立5SA 生命周期 时间不一致一端 86400 秒、另一端 3600 秒差异过大导致协商不通过。6 防火墙 / 路由拦截 ESP、IKE 端口IKEUDP 500、NAT-T UDP 4500ESP协议号 50不是端口是 IP 协议号中间防火墙 /iptables 丢弃 IP 协议 50、UDP 500/45007NAT 穿越配置异常一端有 NAT、一端没开 NAT-T或两端 NAT-T 状态不一致。8 设备固件 / 加密套件兼容性老设备不支持 SHA256/AES-256新设备默认强加密套件不兼容。9逐项核对两端全部算法配置IKE 第一阶段加密算法哈希算法DH 密钥交换组认证方式预共享密钥 / 证书生命周期ESP 第二阶段ESP 加密算法ESP 认证算法TUN模式 / 传输模式PFS 开启 / 关闭 PFS DH 组SA 生命周期建议两端都设为86400 秒先排除时间因素10改成都支持的协议先调通先改成通用兼容套件测试IKEAES-128 SHA1 DH2 modp1024ESPAES-128 SHA1 关闭 PFS 先通再说11检查网络是否不一致或子网冲突检查本端私网、对端私网 网段 掩码配置完全一致无子网冲突完成后检查日志查看第二阶段协商Proposal mismatch、ESP transform not match、PFS mismatch