专业提供企业网络专线 、MPLS VPN、SD-WAN、IPLC、IPLC、海外IDC、云专线等技术方案。
咨询热线:400-028-9798

IPLC

IPSec故障排错之路

发布时间:2021-07-16 10:05:35来源:网络之路博客作者:网络之路作者一天阅读:

[导读]: 前言 IPSec从原理、各个场景已经介绍过很多了,但是对于IPSec来说配置其实理解了原理还是不难的,难就难在出现故障,或者说建立不起来等情况,这个时候就需要依赖之前学过的原理跟...
前言

IPSec从原理、各个场景已经介绍过很多了,但是对于IPSec来说配置其实理解了原理还是不难的,难就难在出现故障,或者说建立不起来等情况,这个时候就需要依赖之前学过的原理跟经验了,原理自己可以多学掌握,经验除了自己积累,还的借助下网络前辈分享的经验,都能够获取有用的帮助,建议配合第37篇以及视频讲解更加,很多现象只能视频才能看出来。

IKE第一阶段容易遇到的问题

(1)IKE没任何反应的可能性

IPSec故障排错之路

这个时候第一想到的是防火墙的安全策略是否放行了,因为IKE与IPSec隧道建立,依赖于Local与untrust(外网接口所在区域)的安全策略,如果没有放行,那么IKE是发起不了的

安全策略放行了,但是还是没有显示,就要查看内外网路由,内网访问对方的数据包,是否抵达了防火墙(可以通过会话表看),如果数据包都没抵达,那么防火墙根本不会去触发建立。如果抵达了,没有触发建立,则看去往对方的路由出口是否跟IPSec调用的接口是一致,因为只有走这个出口出去,才能够触发IKE的协商。

IPSEC调用的接口是否正确,如果接口下没调用或者调用错了接口也会发生没反应的情况。

如果遇到问题建议用流量发起形式建立IPSec,不用自动建立,方便排错。

排错查看命令跟步骤

display interface |     display ip interface br :查看当前内外网接口是否正常,排除掉接口跟链路问题

display ip     routing-table:查看去往内网跟外网的路由是否正常

Ping x.x.x.x :路由正确的情况下内网是否能够通,以及ping -a 源地址 | 目的地址形式。(有的场景有多出口,可能流量并没有从防火墙出去)

display firewall     session table | display firewall statistic :查看是否有会话信息以及安全策略丢包导致的情况,只有安全策略正常配置才能够发起建立。

Display firewall     server-map | display      current-configuration configuration policy-pbr:来查看是否有NAT server与策略路由影响了。

display  acl :数据流是否匹配,如果数据流不匹配是不会触发IKE建立的(自动建立除外)

display ike sa | display  ipsec      statistics:查看当前IKE的发送与接收包的情况,如果有状态显示,说明防火墙已经开始正常发包了,故障解除。

(2)IKE协商不成功的常见故障解析

IPSec故障排错之路

IKE协商不成功,最终会体现在IKE的SA里面,通过display ikesa就可以查看,里面的flag会体现出来,目前为第一阶段,状态是NEG|A,表示在协商中,一定时间内(通常几十秒)没协商起来的话,则会删除。

这种通常是IKE第一阶段没有成功,但是第一阶段里面协商的内容非常的多,这个时候就需要来进行排错了。(这里说下经验,通常情况下排错两边能同时登录一起查看是最佳的,因为建立是两台设备之间的,无法确定问题出在哪台设备上面,所以一起排查更加容易定位到问题,但是在实际中会有很多情况出现,比如你只有一边的登录权限、或者无法登录到对方设备等情况,这个时候也只能先从一端开始排查)

安全策略检查是否正确,建议开启PING允许,方便定位。(就算不允许,排查的时候开启下,后续在关闭)

ping:双方各自ping对方的公网地址,检测基本的连通性。(如果基本连通性都没通,那么对方可能没收到发送过去的IKE协商包,)

display ike proposal:检查两边的IKE安全提议是否一致(认证方式、认证算法、加密算法、DH组、生存时间)

display ike peer:检查两边的参数,这里面的参数就比较重要

(1)remote-address一定要是对方用于IPSec建立的地址。(可能对方存在多个公网IP)

(2)NAT穿越,虽然在华为下一代防火墙里面是默认开启的,但是在华三、华为路由器以及其他厂商里面是没有开启的,并且有的厂商必须要在野蛮模式下才能够进行。

(3)模式:双方一定要处于同一个模式下面,比如主模式或者都是野蛮模式,否则会协商失败。

(4)共享密钥:这个双方一定要保持一致,否则建立不起来。

(5)调用安全提议:这个容易被忽略,忘记调用了,造成两边提议不一样,如果不调用,可能会采用默认的策略(不同厂商有差异)

(6)版本:双方要用相同的版本,比如IKEV1或者IKEV2,注意配置上面的细节问题,像下一代防火墙中,两个版本默认都开启,但是以IKEV2发起优先,但是很多现网中只支持IKEV1的。

(7)ID类型:这个在一端有固定/动态公网IP,一端没有的的情况下特别要注意,大部分以野蛮模式为主,并且起别名的方式来对接,这个时候要注意remote-id-type与local-id-type的匹配。(TP、华三的ER/GR系列路由器、Juniper NS防火墙为分支的时候要特别注意)

display  ipsec      statistics:双方通过查看数据包是否有IKE发起,是否有IKE收到,这样可以判断IKE的包是否双方都能收到没有被限制。(有的地方可以ping通,但是有可能会限制IKE的包)

当这些都检查完毕了,还是没有发现问题?这个也是实际中最头疼的,第一个就靠经验了,第二个利用debug。

(这里特别强调:启用debug的时候,一定要注意精确问题,不要全部开启,否则容易导致设备死机,特别是现网环境!)

terminal monitor

terminal debugging

debugging ikev1 error

Apr  6 2021 12:26:40.250.1 BJ_FWIKE/7/IKE_DEBUG:IKE_ERROR 0:10315 Ikev1 error-info record(peer address:202.100.2.1, error reason: phase1 proposal mismatch,list number: 16).

第一阶段的安全提议不匹配,这个时候就要检测两边的IKE安全提议了。

Apr  6 2021 12:32:56.60.3 BJ_FWIKE/7/IKE_DEBUG:IKE_ERROR 0:8030 Exchange-mode mismatch for peer"202.100.2.1", received exchange type is ID_PROTECTION, localconfiguration (exchange type is AGGRESSIVE, not auto mode, compatiable mode isnot compatible).

Apr  6 2021 12:32:56.60.4 BJ_FWIKE/7/IKE_DEBUG:IKE_ERROR 0:10315 Ikev1 error-info record(peer address:202.100.2.1, error reason: exchange mode mismatch,list number: 34).

两边peer的模式不对,可能一边是主模式,一边是野蛮,这里列举了排错解决的思路与常见的问题,常见的第一阶段错误都能够解决,其余特殊的就要依靠经验了。当第一阶段完成后,会进入第二阶段。(用完后记得关闭debug,直接输入un debug all,全部关闭)

IPSec故障排错之路

当出现了这个状态的时候,就说明第一阶段已经协商OK了,卡在了第二阶段,第二阶段排错步骤(双方都要看)

display  ipsec      proposa:检查双方第二阶段的安全提议是否一致。

display acl all:检查双方受保护流量是否为“镜像”

display ipsec  policy :能查看到当前Policy下面调用的内容是否正确,接口调用是否正确。

当然还是没定位到问题的话,也可以用debug,还是强调用最精细的显示。

terminal monitor

terminal debugging

debugging  ipsec error

Apr  6 2021 13:08:20.850.1 BJ_FWIPSEC/7/IPSEC-DEBUG:

[IPSEC-Error]flow or peer mismatch.(Ifindex=[7], SeqNum=[0],PeerAddress=[202.100.2.1],PeerPort=[500]

提示flow or peer 不匹配,这种提示通常指的是ACL里面两边的内容不匹配

Apr  6 2021 13:13:34.760.2 BJ_FWIPSEC/7/IPSEC-DEBUG:

[IPSEC-Error]phase2 proposal mismatch.(Ifindex=[7], SeqNum=[0],PeerAddress=[202.100.2.1],PeerPort=[500])

Apr  6 2021 13:13:35.390.1 BJ_FWIPSEC/7/IPSEC-DEBUG:IPSEC_ERROR 20:1363 IKE is negotiating SA for IPsec policy:p1-10

这个提示主要看phase2 proposal mismatch,这个提示的是第二阶段的安全提议不匹配。(这里要注意PFS,有的厂家默认是开启的,容易被忽略)

IPSec隧道终于起来了,业务不通?

IPSec故障排错之路

隧道建立起来后,业务不通,这个也是比较常见的,这里介绍比较容易遇到的情况。

(1)client1发出的数据包能够正常抵达BJ防火墙以及转发出去。(可能会遇到内网是三层交换机当网关等场景,但是没写路由过来)

(2)安全策略明确放行了

Client1与server1的双向放行,如果单向的话,可能会出现一边可以通,一边不能通的情况

Local与untrust之间的IKE 500、4500、ESP双向放行

NAT策略,通常会配置trust到untrust的NAT策略,如果配置了一定要配置nonat,顺序要放到前面

互联网设备没有过滤UDP 500/4500、ESP报文(通过display  ipsec      statistics可以看加解密情况来判断)

CS防火墙需要有到server1的路由,保障连通性(包括安全策略放行等,否则会造成单向通)

IPSec性能等问题

在实际中也会遇到IPSec建立后,比如丢包、延迟大、不稳定等情况,特别是多厂商的情况下,那么这种情况下排错就非常困难,只能采用一些排除法,把能判断的先排除掉。

1、IPSec反复进行隧道协商建立

两边之间运营商链路不稳定,这种情况可能出现在不同运营商之间的情况会多些。

DPD的时间检测太快,导致误认为对方出现问题,把SA信息清除掉了。

生存时间:IKE默认的时间为一天,IPSec SA则为一小时,但是在华为里面还有一个流量的生存时间,这个流量生存时间,有的厂商并不支持,如果分支到总部的流量非常大,把这个流量生成时间消耗完了,但是分支感知不到,那么总部这边会把SA信息清空,更糟糕的是如果总部是模板形式的话,不能主动发起建立,导致隧道断开。

2、设备性能不够

防火墙承载的业务不单单有IPSec,可能还有策略路由、安全策略、选路、以及IPS等,这个时候都一起工作的时候,随着IPSec的隧道越多,流量越大,就会出现性能不够的情况,特别是在分支之间的流量都通过总部去访问的时候,对总部设备的压力更大。

display  cpu-usage:查看CPU的利用率,是否超过80%以上

display     current-configuration:优化一些不必要的配置,或者暂时关闭某些功能,看看是否改善

display  firewall      statistics system      transmitted:查看是否有分片,因为IPSec由于包结构加大,分片的可能性更大。所以建议在部署IPSec的网络中,把MTU 1350~1400,可以减少分片的可能性。(ESP头部最少占用56个字节,隧道模式会形成新的IP头部,占用20个字节,如果GRE出现会占用4~12,PPPOE占用8个,NAT-T占用8个)

结尾

这个就是整体IPSec相关的排错,从第一阶段、第二阶段、以及通了后业务不通等方明,把常见的故障都列出来了,配合视频讲解更加理解深刻,另外实际环境由于厂商过多,很多特殊的情况都会发生,这个就只能自己经验的积累,多查询双方设备的特性跟案例库来进行解决,往往对接容易出现问题的就是在两个不同厂商之间。

以上就是IPSec故障排错之路的介绍,Vecloud提供全球网络优化服务、MPL专线、SD-WAN组网、IPLC专线海外专线业务。

免责声明:部分文章信息来源于网络以及网友投稿,本网站只负责对文章进行整理、排版、编辑,是出于传递 更多信息之目的,并不意味着赞同其观点或证实其内容的真实性,如本站文章和转稿涉及版权等问题,请作者在及时联系我们本站,我们会尽快处理。

标题:IPSec故障排错之路

TAG标签: IPSEC VPN

地址:http://www.vecloud.com.cn/haiwaizhuanxian/310.html