***排错是个很头疼的问题,juniper原先的ssg系列登录到web就会有看到设计很好的日志记录界面,一眼就能看出问题所在。相对而言,srx上进行traceoption比较麻烦,很多错误都不明显。

   这篇文章不是什么正儿八经的文档,只是我自己实验和工作心得。上个月在处理一次juniper srx和Cisco as防火墙建立***的case时候遇到了问题(下面会讲到)。于是我打算反推过来,看看srx上使用traceoption进行***排错会有哪些好玩的地方。


1.实验拓扑:

***排错拓扑.png

2.实验过程:

拓扑很简单,分别用两台srx340模拟local和remote,先进行正常的***配置:

屏幕快照 2018-02-01 17.42.36.png

现在我们开始搞破坏,然后通过traceoption来查看相关的日志记录。

第一步,修改域分享密码,把原先的Juniper换成Cisco,发现隧道down掉了:

preshare-key.png

我们开始查看debub文件,搜索关键字设置为error:

[Feb  1 10:14:24]<none>:500 (Responder) <-> 2.2.2.2:500 { 8bf32842 80c83c52 - c534184e 9f9eb944 [0] / 0x6a1843f7 } Info; Notification data has attribute list

[Feb  1 10:14:24]<none>:500 (Responder) <-> 2.2.2.2:500 { 8bf32842 80c83c52 - c534184e 9f9eb944 [0] / 0x6a1843f7 } Info; Notify message version = 1

[Feb  1 10:14:24]<none>:500 (Responder) <-> 2.2.2.2:500 { 8bf32842 80c83c52 - c534184e 9f9eb944 [0] / 0x6a1843f7 } Info; Offending payload type = 159

[Feb  1 10:14:24]<none>:500 (Responder) <-> 2.2.2.2:500 { 8bf32842 80c83c52 - c534184e 9f9eb944 [0] / 0x6a1843f7 } Info; Offending payload data offset = 0

[Feb  1 10:14:24]<none>:500 (Responder) <-> 2.2.2.2:500 { 8bf32842 80c83c52 - c534184e 9f9eb944 [0] / 0x6a1843f7 } Info; Error text = Incorrect pre-shared key (Invalid next payload value)

[Feb  1 10:14:24]<none>:500 (Responder) <-> 2.2.2.2:500 { 8bf32842 80c83c52 - c534184e 9f9eb944 [0] / 0x6a1843f7 } Info; Offending message id = 0x00000000

[Feb  1 10:14:24]<none>:500 (Responder) <-> 2.2.2.2:500 { 8bf32842 80c83c52 - c534184e 9f9eb944 [0] / 0x6a1843f7 } Info; Received notify err = Invalid payload type (1) to isakmp sa, delete it

红色的字体很清晰的显示:不正确的域分享密码。


第二步,继续搞破坏,之前的实验为了偷懒,我都是用的预设的加密和认证。现在使用自定义的proposals,我在两段的authentication-algorithm做个小手脚:

au-l1.3.png

au-l1.4.png

然后***自然就down掉了:

***down.png

继续看debug文件(***排错对于菜鸟真是头疼,现在做实验知道了结果反推回去真是神清气爽啊):

仍然搜索关键字error:

[Feb  1 10:31:34]ike_st_i_private: Start

[Feb  1 10:31:34]ike_send_notify: Connected, SA = { b5683f91 580f05d7 - 3780e055 cd8cc990}, nego = 0

[Feb  1 10:31:34]1.1.1.2:500 (Initiator) <-> 2.2.2.2:500 { b5683f91 580f05d7 - 3780e055 cd8cc990 [-1] / 0x00000000 } IP; Connection got error = 14, calling callback

[Feb  1 10:31:34]ikev2_fb_v1_encr_id_to_v2_id: Unknown IKE encryption identifier -1

[Feb  1 10:31:34]ikev2_fb_v1_hash_id_to_v2_prf_id: Unknown IKE hash alg identifier -1

[Feb  1 10:31:34]ikev2_fb_v1_hash_id_to_v2_integ_id: Unknown IKE hash alg identifier -1

[Feb  1 10:31:34]IKE negotiation fail for local:1.1.1.2, remote:2.2.2.2 IKEv1 with status: No proposal chosen

[Feb  1 10:31:34]  IKEv1 Error : No proposal chosen

[Feb  1 10:31:34]IPSec Rekey for SPI 0x0 failed

[Feb  1 10:31:34]IPSec SA done callback called for sa-cfg P1 local:1.1.1.2, remote:2.2.2.2 IKEv1 with status No proposal chosen

出现了多个error,failed。我们可以断定是在IKEV1阶段出现了问题,缩小了排错的范围(修改:IKE V1的意思是使用的IKE 版本1 ,不是阶段1,现在已经有了IKE V2,可以更快的协商并且防止dos***,从而提供安全性)。


第三步,我们开始对第二阶段搞破坏,正常情况下,***建立成功的日志会显示:

正常.png

翻译过来就是:阶段二连接成功。

搞破坏之前先讲一讲我肤浅的理解,二阶段的参数不匹配,应该不影响一阶段的隧道的建立。但是这次和思科对接的case里面,第一阶段一直无法建立,而对端的思科工程师说他的debug文件显示是我二阶段的感兴趣流没有匹配:

刚兴趣流.png

但是这个我和思科的兄弟确认了好几遍没有问题。最后发现问题是出在二阶段的参数上面。

回到Juniper srx和srx对接的环境中来模拟,我们修改二阶段的Diffie-Hellman Group:

group14.png

gorup2.png

区别于juniper和cisco对接第一阶段都无法建立,SRX和SRX对接的话,第一阶段是ok的,第二阶段down了:

二阶段.png

继续查看traceoption日志:

[Feb  1 10:58:00]IPSec negotiation failed for SA-CFG P1 for local:1.1.1.2, remote:2.2.2.2 IKEv1. status: No proposal chosen

[Feb  1 10:58:00]   P2 ed info: flags 0x8082, P2 error: Error ok

[Feb  1 10:58:00]  IKEv1 Error : No proposal chosen

出现的代码和上面步骤二的一致,都是 IKEv1 Error : No proposal chosen

这说明IKEv1 Error : No proposal chosen并不是仅仅针对于第一阶段而言的(修改:v1的意思不是阶段1


    我并不知道为什么和思科的设备第一阶段都无法建立。回过头来看,双方的debug文件似乎都无法准确定位问题的所在?这里就需要老司机们答疑解惑了,我参考了Juniper的kb文档并且和对端的思科设备配置文件对比了一下,似乎没有找到思科的配置上定义了这个参数,需要思科的老司机们解释下下。后来用户的网络已经联通,管理权限交还给了用户,我也没有继续深究下去。

    这些就是我做的简单的实验,JUNIPER SRX系列支持基于路由和基于策略的IPSEC ×××,也支持dynamic ***和ssl ***。去年遇到过一个HA模式下dynamic ***问题,下次就机会模拟下HA环境dynamic ***做些好玩的实验。