阿里雲國際帳號代理 阿裡雲 VPN 網關階段二協商失敗（IPsec SA Failed）金鑰與感興趣流匹配
先弄清楚报错的真实含义
\n阿里雲國際帳號代理 阿里云 VPN 网关出现“IPsec SA Failed”时，很多人第一反应是隧道坏了，但真正要先分清的是：到底是第一阶段没有握手成功，还是第一阶段已经建立，卡在第二阶段的 IPsec SA 协商。阶段二失败，通常说明双方已经走到生成数据加密通道这一步，却在参数、流量范围或安全策略上没有对齐，最后导致业务流量无法进入隧道。
\n这类问题最让人头疼的地方，不是错误本身复杂，而是它的表现很容易误导排查方向。表面上看，VPN 可能还能显示在线，控制台里也未必有特别明显的红色告警，可实际业务就是不通。此时如果只盯着某一个参数反复改，很容易把本来正确的配置也改乱，最后连恢复路径都找不到。
\n所以，面对“IPsec SA Failed”这类阶段二协商失败，第一原则不是先猜，而是先拆。先把隧道的协商层次拆开，把双方配置拆开，把流量范围拆开。只要把“密钥、算法、感兴趣流、路由、放行策略”这几类问题分开看，定位速度会快很多。
\n\n阶段二到底在匹配什么
\n阶段一和阶段二的分工
\nIPsec 隧道协商一般分为两个阶段。第一阶段负责建立安全的控制通道，核心是身份认证和密钥交换，也就是双方先确认彼此是谁，能不能建立受保护的协商环境。第二阶段则是在这个安全通道里，继续协商真正承载业务流量的 IPsec SA，决定哪些流量可以进隧道、用什么算法加密、多久重协商一次。
\n很多人把阶段一和阶段二混在一起看，结果把问题方向带偏。比如预共享密钥不一致，往往更像第一阶段问题；而阶段二失败，更常见的是加密套件不一致、PFS 参数不一致、感兴趣流不一致，或者双方网段、掩码、方向没有镜像一致。当然，在一些设备日志里，错误提示可能并不够细，表面显示的是同一个“SA Failed”，但真正原因并不相同。
\n感兴趣流是什么
\n感兴趣流也叫选择器，简单说就是“哪些流量应该被这条 VPN 隧道接管”。在基于策略的协商里，它通常会包含本地网段、对端网段、协议类型，甚至端口范围；在路由型场景里，表现形式可能稍微不同，但本质一样，都是在定义流量边界。只要双方对这个边界的理解不一致，第二阶段就很难成功。
\n最容易出错的地方，是把感兴趣流理解成“只要能互通的网段就行”。实际上，协商时要的是双方完全一致的描述，而不是大概差不多。比如一边写的是 10.10.0.0/16 对 172.16.0.0/16，另一边却写成 10.10.1.0/24 对 172.16.0.0/16，哪怕业务上看起来都属于同一网络，协商层面仍然可能直接失败。
\n\n最常见的几类原因
\n预共享密钥不一致
\n虽然密钥问题更常见于第一阶段，但实际排查中仍然不能忽略。很多运维同学会在对端设备和阿里云 VPN 网关之间反复切换配置模板，结果把预共享密钥改成了不同版本，或者在复制时带入了空格、换行、特殊字符。设备界面里看起来一模一样，真正参与认证时却已经不一致，最终导致整个协商链路不稳定。
\n如果你看到阶段二失败，但第一阶段也时好时坏，或者日志里同时出现 IKE 认证异常，那就不要只盯着感兴趣流了，先把预共享密钥重新逐字核对一遍。密钥问题的特点是简单、致命，而且经常被人低估。
\n加密套件、认证算法或 PFS 不一致
\n阶段二需要双方对加密算法、认证算法、DH 组、PFS 是否启用、生命周期等参数达成一致。这里最容易出问题的，是双方各自沿用了默认模板，却没有逐项确认。比如一边使用 AES256 和 SHA256，另一边还停留在 AES128 和 SHA1；一边开启 PFS 14，另一边没有启用；一边生命周期 3600 秒，另一边 28800 秒。某些参数差异只会导致重协商失败，某些差异则会让第一次建立就失败。
\n别小看这些参数。很多设备的默认值看似合理，但默认值并不代表兼容。尤其是旧设备、云上网关、第三方防火墙混合接入时，算法能力、默认策略和厂商实现细节都会影响协商结果。真正稳妥的做法，是双方先选一组最保守、最常见的组合，再确认通了以后再考虑优化。
\n阿里雲國際帳號代理 感兴趣流不对称
\n这是阶段二失败里最典型的一类问题。阿里云侧定义的是本地 VPC 网段到对端 IDC 网段，但对端设备却把顺序写反了，或者只配置了单向策略，结果协商时双方根本不是在描述同一个流。还有一种情况更隐蔽：双方都写对了网段，但掩码不一样，或者其中一侧只放行了部分子网，导致表面上“看着能对上”，实际上并不完全匹配。
\n感兴趣流的核心原则只有一句话：双方要互相镜像。你在云上写本地网段到对端网段，对端就要写对端网段到本地网段；你在一边写 /16，另一边就不能只写 /24；你在一边只放某些业务网段，另一边也必须按同样范围配置。只要有一处不对称，阶段二就可能协商失败，或者协商成功后流量不进隧道。
\n网段重叠或掩码写错
\n网段重叠是另一个高频坑。比如本地机房和阿里云 VPC 恰好使用了相同的 10.0.0.0 段，或者不同业务线各自规划地址时互相踩了网段，结果 IPsec 在选择转发路径时无法判断哪些包应该走隧道，哪些包应该本地直达。还有人会把掩码写错成 /24 或 /23，自己测试单台主机似乎没问题，一旦访问更大范围的地址就出错。
\n在云网互联场景里，地址规划比设备配置更重要。只要底层地址设计有冲突，再精细的隧道参数也只是临时补丁，迟早会在扩容、迁移或新增网段时再次暴露出来。
\n路由、ACL 和安全组没有放行
\n有些场景里，第二阶段其实已经成功了，但业务还是不通，现场就会误判成阶段二失败。原因可能是路由没指向 VPN 网关，安全组没有放行来源网段，云下防火墙没有允许对端网段的回程流量，或者 ACL 只放行了 ICMP 却没有放通业务端口。尤其是在应用只测试 ping 的时候，很多人会以为 ICMP 通不代表 VPN 不通，实际上有时只是策略太严。
\n所以排查时要区分“协商失败”和“协商成功但业务不通”。前者看的是 SA 是否建立，后者看的是流量是否真正进了隧道。两者相关，但不是一回事。
\n多条策略只配了一条
\n如果本地和阿里云之间不是单一网段，而是多个子网、多个业务系统同时互联，就很容易出现只配了一条策略，其他网段没配全的问题。协商时，设备可能只针对其中一条感兴趣流建立 SA，别的业务流就被丢弃，表现出来就是部分应用正常、部分应用失败，或者白天可用、夜里某条链路切换后突然失败。
\n这种问题的麻烦在于它不像完全不通那样明显，而是带着明显的“间歇性”和“选择性”。一旦业务量上来，问题就会被放大。
\n\n推荐的排查顺序
\n第一步：先判断到底卡在哪一阶段
\n先看阿里云 VPN 网关和对端设备的日志，确认是第一阶段认证失败，还是第二阶段 SA 协商失败。如果第一阶段都没有成功，先不要急着查感兴趣流，先查密钥、IKE 版本和基础连通性；如果第一阶段已经建立，第二阶段失败，那就把注意力放到加密套件、PFS、选择器和路由上。这个判断一旦做错，后面的排查会全部跑偏。
\n第二步：逐项比对双方配置
\n建议按固定顺序核对，不要想到哪里改到哪里。先看预共享密钥，再看 IKE 版本、加密算法、认证算法、DH 组和 PFS，然后看生命周期，最后看感兴趣流。这样做的好处是，一旦某个参数不一致，你可以马上停下来，不必继续猜下一个可能性。
\n1. 预共享密钥
2. IKE 版本
3. 加密算法
4. 认证算法
5. DH 组
6. PFS
7. 生命周期
8. 本地网段
9. 对端网段
10. 策略方向第三步：检查感兴趣流是否完全镜像
\n把双方配置写成一张对照表，逐条比对最有效。比如本地 IDC 是 10.10.0.0/16，阿里云 VPC 是 172.16.0.0/16，那么本地侧应该是 10.10.0.0/16 到 172.16.0.0/16，对端侧就应该反过来写 172.16.0.0/16 到 10.10.0.0/16。只要一边写成了更小的掩码、少了某个子网，或者顺序写错，协商很容易失败。
\n如果你使用的是更细粒度的业务策略，还要检查协议和端口。比如某些防火墙会把策略写成只允许 TCP 443 或 UDP 500，这时就要确认双方的定义一致，否则 VPN 协商虽然看着正常，后续业务也可能进不去。
\n第四步：确认路由和放行策略
\n在阿里云侧，要确认 VPC 路由表已经正确指向 VPN 网关，相关网段没有被其他更高优先级路由覆盖；在本地侧，要确认回程路由能把返回流量送回隧道，而不是被默认路由带走。与此同时，云上安全组和本地防火墙都要检查，不要只放了单向流量，也不要只测管理端口而忽略业务端口。
\n很多人把路由和策略看成“后置问题”，其实它们往往是让协商看起来失败的真正原因。隧道建立了，包却没走进来，最终日志里仍然会冒出各种 SA 相关报错，极易误导判断。
\n第五步：清理旧 SA 后重新协商
\n阿里雲國際帳號代理 配置改完以后，不要直接拿旧状态继续测试。旧的 SA、过期的协商缓存、对端设备残留的临时状态，都可能让你看到旧问题重复出现。最稳妥的做法，是清理旧会话后重新发起协商，再观察日志和状态变化。这样你看到的才是新配置的真实结果，而不是旧状态的残影。
\n\n一个容易踩坑的例子
\n假设阿里云侧配置的本地网段是 192.168.10.0/24，对端网段是 10.0.0.0/16；本地机房设备也确实写了这两个网段，但它把方向写成了 10.0.0.0/16 到 192.168.10.0/24。看起来内容没有少，实际上双方各自都在描述自己那一侧的流量范围，却没有把“本地到对端”和“对端到本地”镜像起来。结果就是第一眼像是密钥没对上，第二眼像是算法不兼容，实际上真正问题只是选择器方向没对齐。
\n如果再叠加一个小错误，比如本地侧的掩码从 /24 写成 /23，问题就会变得更像随机故障。某些主机能通，某些主机不通，测试人员会以为是防火墙或服务器故障。其实只要把网段、掩码和方向统一起来，很多“玄学问题”会立刻消失。
\n\n配置时的实用原则
\n- \n
- 先定地址规划，再定隧道参数，不要靠隧道去修地址冲突。 \n
- 双方参数尽量成对配置，尤其是网段、掩码、方向和算法。 \n
- 优先使用双方都明确支持的算法组合，避免默认值碰撞。 \n
- 有多条业务网段时，逐条确认，不要用一条策略代替全部。 \n
- 改完配置后清理旧 SA，再做一次完整连通性测试。 \n
还有一个很实用的习惯，是把双方配置整理成同一份对照表。表里不要只写当前值，还要写清楚期望值、变更时间、验证结果。这样一来，出现“IPsec SA Failed”时，你不需要从头翻聊天记录，也不需要到处找截图，直接看表就能知道哪一项最可疑。
\n\n结语
\n阿里云 VPN 网关的阶段二协商失败，看起来像是一个报错，实际上往往是多项配置没有对齐后的结果。密钥要一致，算法要一致，感兴趣流要镜像，路由和放行策略也要完整闭环。只要你能把问题拆成这几层，排查就不会只靠经验碰运气，而是可以沿着清晰的顺序一项一项验证。
\n真正高效的故障处理，不是把错误信息背下来，而是能从错误信息反推协商在哪一步断掉、哪一类参数最可能不一致、哪一个配置最值得先改。把这套思路养成习惯之后，遇到“IPsec SA Failed”时，你会发现它并没有想象中那么难，难的是一开始没有找到正确的切口。
" }