JUNIPER SRX ***排错实验1.0

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

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

1.实验拓扑：

2.实验过程：

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

如今咱们开始搞破坏，而后经过traceoption来查看相关的日志记录。

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

咱们开始查看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作个小手脚：

而后***天然就down掉了：

继续看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***，从而提供安全性）。

第三步，咱们开始对第二阶段搞破坏，正常状况下，***创建成功的日志会显示：

翻译过来就是：阶段二链接成功。

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

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

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

区别于juniper和cisco对接第一阶段都没法创建，SRX和SRX对接的话，第一阶段是ok的，第二阶段down了：

继续查看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 ***作些好玩的实验。