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 ***作些好玩的實驗。