JUNIPER SRX ***排错实验1.0-yubj314的博客

周翔

　　***排错是个很头疼的问题，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>　　[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>
　　[Feb  1 10:31:34]ikev2_fb_v1_hash_id_to_v2_prf_id: Unknown IKE hash alg>
　　[Feb  1 10:31:34]ikev2_fb_v1_hash_id_to_v2_integ_id: Unknown IKE hash alg>　　[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 ***做些好玩的实验。