***排錯是個很頭疼的問題，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 ***做些好玩的實驗。