• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

IPSecvpn 隔段时间就会出现某些连接无法通讯

5小时前提问
  • 0关注
  • 0收藏,35浏览
MaX3n 零段
粉丝:0人 关注:0人

问题描述:

总部路由器UR7208
分部路由器MSR3620
总部和分部之间做了IPsecvpn,因为总部和分部之间有网段冲突,所以我IPsecvpn所做的感兴趣了都是基于端到端的

现在问题是,如果隔了一两天,某台主机没有访问服务器192.168.28.234,就有可能,这台主机就没办法访问服务器了,但是在
主机无法访问服务器的时候,用服务器去ping这台主机,是能ping通的,但是主机ping服务器就不行,必须把这个Ipsecvpn的全部连接都重置,
才能正常通讯,请问各位老师应该怎样排查?

3 个回答
粉丝:23人 关注:1人

你描述的现象(主机长时间不访问服务器后无法发起通信,但反向ping能恢复)是一个IPsec VPN中比较典型的问题。根本原因在于IPsec安全联盟(IPsec SA)的空闲超时

简单来说,当一条连接长时间没有数据流量时,两端的IPsec SA可能会因达到生命周期(Lifetime)而失效。当主机再次尝试发起新连接时,由于旧的SA已失效,且新的SA协商可能因“感兴趣流(ACL)”配置不完全对等或触发机制不完善而未能成功建立,导致通信失败。而从服务器反向ping主机之所以能恢复,是因为它恰好触发了重新协商IPsec SA的过程

解决这个问题的核心思路是:让IPsec隧道始终保持“活跃”状态,避免SA因空闲而超时。

🔧 解决方案

你可以尝试以下两种方案,建议优先尝试方案一

方案一:开启DPD(Dead Peer Detection,推荐)

DPD是一种用于检测IPsec隧道对端是否在线的机制。它可以主动探测对端状态,并在需要时触发重新协商,从而避免SA超时

配置命令(在UR7208和MSR3620上均需配置):

bash
system-view ike dpd interval 10 retry 3 periodic
  • interval 10:每隔10秒发送一次DPD探测报文。

  • retry 3:如果连续3次探测无响应,则认为对端失效。

  • periodic:周期性地发送探测,这是实现“保活”的关键参数。

配置完成后,设备会周期性地检查隧道状态,从而有效防止因空闲而导致的超时中断

方案二:配置NQA(Network Quality Analyzer)保活

如果DPD方案因某些原因效果不佳,可以使用NQA来模拟业务流量,人为地让隧道保持活跃

配置命令(在总部UR7208上配置,持续ping分部的内网IP):

bash
system-view nqa entry admin test1 type icmp-echo destination ip 192.168.28.234 # 替换为分部服务器的IP source ip [总部内网IP] # 替换为总部发起探测的内网IP next-hop [分部公网IP] # 替换为MSR3620的公网IP probe count 10 probe timeout 500 frequency 5000 quit nqa schedule admin test1 start-time now lifetime forever

这个配置会创建一个持续进行的ICMP测试,每5秒从总部内网向分部服务器发起一次ping,从而保证隧道中始终有流量通过,避免SA空闲超时。

暂无评论

粉丝:12人 关注:9人

排查步骤:
1. 检查IPSec SA状态:在总部和分部设备上执行display ipsec sa,确认SA是否存在且状态正常(如inbound/outbound SPI是否有效)。
2. 查看NAT策略:若存在NAT,确认感兴趣流是否被正确排除NAT(如总部/分部内部地址未被NAT转换)。
3. 检查ACL匹配:确认两端ACL是否精确匹配主机与服务器的端到端流量(如总部ACL允许主机→服务器,分部ACL允许服务器→主机)。
4. 查看ike sa状态:执行display ike sa,确认IKE SA是否正常(状态为established)。
5. 检查DPD配置:确认两端是否开启DPD(ike dpd),若未开启可能导致SA超时未检测。
6. 抓包分析:在主机或服务器侧抓包,查看主机ping服务器时是否有ESP包发出,服务器侧是否收到;服务器ping主机时是否有ESP包返回。
7. 检查路由:确认主机到服务器的路由是否指向IPSec隧道,服务器到主机的路由是否正确。
关键命令:
总部/分部:display ipsec sa、display ike sa、display acl all、display nat policy、tracert -d 192.168.28.234(主机侧)。
可能原因:
SA超时未重建(DPD未开启或配置不当)。
ACL匹配方向错误(仅单向匹配)。
NAT策略干扰(感兴趣流被NAT转换)。
路由单向失效(主机侧路由丢失)。

暂无评论

粉丝:20人 关注:2人

  1. 尽量合并同网段感兴趣流,减少 SA 条目数量,降低独立老化概率;
  2. 关闭设备全局 DPI / 应用识别对 ESP/500/4500 端口的限流拦截;
  3. 检查两端 IKE 协商生存时间必须保持一致,否则协商异常;
  4. 若使用 IKEv2,ikev2 auto-reconnect稳定性优于 IKEv1,可升级协商版本。

故障总结

你的故障是典型单向 SA 老化无自动重建:主机闲置 5 分钟后正向 IPSec SA 被删除,服务器主动访问仅生成反向 SA,主机再次发起流量无法触发 IKE 重建;重置隧道会重新协商全部双向 SA,临时恢复。核心解决手段:开启ike auto-reconnect + 延长 SA 流量老化时间 + 配置 IPSec 保活流量 + 双向完整 ACL。

暂无评论

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

分享扩散:

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作

举报

×

侵犯我的权益 >
对根叔社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明