主模式第六包(收包)：main_inR3
1. 序言
main_inR3()函數是ISAKMP協商過程中第一階段的最後一個報文的接收處理函數，它的作用同main_inI3_outR3()部分功能相同：完成對對端身份的認證。他們的不同之處在於不在需要響應報文（如果不考慮第二階段的話）。此包處理完畢後，發起端便成功建立了ISAKMP SA, 完成了第一階段主模式的協商。後續便是第二階段的協商。這裏我們主要說明main_inR3的函數調用關係、處理流程以及對源碼的註釋分析，關於main_inR3的上下文環境暫不敘述，留給後面的文章進行更新。
ISAKMP協商報文的處理流程都比較複雜，此函數在協商的報文處理函數中比較複雜的，因此個人學習期間難免有遺漏和理解錯誤的地方，請大家多多批評指正。
目前主要是整理源碼中的處理裏流程和實現邏輯，尚未深入比較細節的處理；後續在我整理完畢使用主模式協商的9個報文後，我再次結合代碼整理每一個報文的詳細流程，到時把每一個報文的注意事項、作用，處理方式做一個整體上的把握。同時結合書本上的描述來解釋代碼層的實現。
ISAKMP主模式協商流程如下：
本文要說明的便是第⑥包的接收函數：main_inR3();
2. 函數調用關係
main_inR3()函數的調用層次少了很多（如果不考慮加解密、證書認證的話），它的調用關係圖如下所示
3. 第⑥個報文接收流程圖
第⑥個報文的接收流程main_inR3的功能可以分爲三類(如果把建立ISAKMP SA也看作一類的話)：
- 解析對方的身份標識(ID)和證書載荷，匹配對方的身份標識
- 身份驗證
- 預共享祕鑰
- 數字證書
- 建立ISAKMP SA
流程圖下圖：
4. 源碼分析
由於main_R3()的處理流程和main_inI3_outR3()中的部分處理流程調用了相同的函數接口，因此無需再進行說明，如果有疑問可以查看main_inI3_outR3()的中的源碼部分。
5. 總結
openswan的源碼確實難度很高，雖然用了很長的時間來看主模式的6個報文7個主要的函數接口，前後花費了一個月時間吧（之前陸陸續續看過部分接口），但是學習的時候比較淺，沒有深層次的理解。最主要包括以下幾個方面：
-
報文的加解密
報文加密、解密是在第⑤⑥個報文中才有的，關於這部分的功能（加密、哈希、數字證書籤名驗籤、預共享密鑰等），只知道它是在做這種處理，基本沒有深入去分析代碼。這個主要是由於看不懂，內心裏有種牴觸心理；其次是不想直接深入學習這部分，先學習整體處理框架，然後再慢慢深入學習這部分功能。即“先廣度優先搜索，再深度優先搜索”
-
算法相關的操作
這裏的算法相關，我是想表達對於策略的配置解析存儲算法、如何與報文中的載荷相對應、支持的算法類型、協商時處理對方建議載荷的原則等等問題。這部分有的可能已經在協商流程中有所涉及，但是關於算法的存儲等是在這部分之前的流程中處理的(
whack_handle())，因此沒有過多學習。後面再補充whack命令相關的知識。 -
連接和狀態之間的聯繫
主要的疑惑是不清楚他們成員之間的關係，可能是特別大，同時關係有比較複雜的緣故。狀態是一個動態的概念，即協商過程中的參數；連接是我們的隧道配置信息，基本是個固定的結構。他們是如何維護、以及協商過程中如何聯繫起來，這部分沒有系統整理和分析過。舉個簡單的例子：NAT-T在ISAKMP中是如何完成協商的？ 這個我之前處理過一個bug,因此可能分析過協商過程中的聯繫，但是其他的我就不得而知了。
任重而道遠，繼續努力吧。