IPsec 目的是用來解決兩個(gè)IP之間數(shù)據(jù)可靠，安全傳輸?shù)膯栴}。
這個(gè)問題可以拆分開為幾個(gè)問題：
- 確保傳輸過來的數(shù)據(jù)是沒有被篡改過的（data integrity）
- 確保數(shù)據(jù)是對(duì)方傳過來的（data origin authentication)
- 數(shù)據(jù)不被其他人偷看（confidentiality)
另外一個(gè)要避免中途有人截取了這些數(shù)據(jù)然后故意重傳，即重放攻擊（replay attacks），這個(gè)問題先不討論
為了解決上面這幾個(gè)問題，我們先考慮下面幾種情況： - 數(shù)據(jù)被無意中修改
假設(shè)我們使用知名的 md5 算法，把傳輸?shù)臄?shù)據(jù)算出一個(gè)哈希值，然后放在數(shù)據(jù)包的某個(gè)位置。收到數(shù)據(jù)后我們?nèi)ニ阆缕涔Ｊ遣皇歉綆У墓Ｖ狄恢?，如果不一致則說明數(shù)據(jù)被改過了。如果有人惡意偽造數(shù)據(jù)，把哈希值也改了，這種技術(shù)就防止不了。 - 如何防止數(shù)據(jù)惡意被篡改
要防止數(shù)據(jù)被惡意篡改，我們假設(shè)數(shù)據(jù)傳輸雙方都知道一個(gè)密碼，然后把密碼和數(shù)據(jù)拼接起來，算出一個(gè)哈希值作為驗(yàn)證。由于第三方不知道密碼，無法偽造，因此通過這種方式，我們就解決了上面三個(gè)問題中的前兩個(gè)問題。
在有密碼的情況下，雙方可以用加密算法來加密和解密，也就解決了第三個(gè)問題。
上面講的是一個(gè)一個(gè)從技術(shù)理論角度來看 IPsec 的問題，而在實(shí)際上 IPsec 的應(yīng)用中，往往會(huì)用到下面這些術(shù)語：
- 認(rèn)證頭（AH）
認(rèn)證頭是干什么的呢？其實(shí)際上就是解決了上面的第一，第二個(gè)問題。 - 封裝安全載荷（ESP）
這個(gè)技術(shù)實(shí)際上是解決了上面的三個(gè)問題
從表面來看，似乎后者是可以完全替代前者，但是實(shí)際上后者算的哈希值只包括了 IP 包承載的數(shù)據(jù)（payload），而前者把 IP 頭的部分信息也算在里面了。兩者可以選著用或者只用其中一種，視情況而定。
上面這兩個(gè)技術(shù)都需要密碼和相關(guān)算法，其通過安全參數(shù)索引（SPI）這個(gè)字段來獲得，那么想一下密碼和算法這些信息保存在哪里？這就牽扯到另外一個(gè)技術(shù)，即安全關(guān)聯(lián)（SA Security association），里面保存了密碼以及相關(guān)算法信息。
講到這里，其實(shí)還有問題，那就是前面提到的密碼是怎么得到的，加密算法又是怎么協(xié)商的，常見的解決這個(gè)問題依賴 IKE([Internet Key Exchange) 這個(gè)組件，其通過協(xié)商，最終會(huì)生成安全關(guān)聯(lián)。目前 IKE最新版本是 IKEv2。
IKE 交互過程分為兩個(gè)階段：
- 第一階段，通過 DH 密鑰交換算法根據(jù)原始信息生成一個(gè)密碼，這個(gè)密碼被用來加密后續(xù)的 IKE 數(shù)據(jù)。這個(gè)原始信息可以是預(yù)共享密鑰（PSK），密鑰對(duì)等。第一階段可以工作在Main Mode或者Quick Mode，前者有加密，比較安全。
其中第一個(gè)階段又分為兩個(gè)步驟，第一步稱作 IKE_SA_INIT，其主要作用是交換基本信息，包括要采用的哈希算法，加密算法，隨機(jī)數(shù)（nonce）并且執(zhí)行了一步 DH 交換。（出于簡(jiǎn)化起見，先不討論公鑰這種情況。）這步基礎(chǔ)上，實(shí)際上兩端可以得出了一個(gè)共識(shí)的密鑰，這就是 DH 交換算法的功能。第二步則稱為 IKE_AUTH，這一步中，雙方用協(xié)商好的算法和共識(shí)算法對(duì)之前的消息進(jìn)行了簽名確認(rèn)，最終創(chuàng)建了第一個(gè) SA。推測(cè)這個(gè) SA 并不為任何 IPsec 的連接使用，而只給 IKE 使用。 - 第二階段，根據(jù)前面階段的密碼來協(xié)商和創(chuàng)建更多的安全關(guān)聯(lián)（SA）信息。
第二階段，雖然在配置層面上都是 IKE 的配置，但是在實(shí)際上所有的配置應(yīng)該都是指 IPsec 的配置。這里又包括兩個(gè)考慮點(diǎn)：第一是用 ESP 還是 AH，現(xiàn)實(shí)世界里面我們直接拋棄 AH 采用 ESP。第二是 ESP 用什么算法來加密。這個(gè)配置項(xiàng)在 openswan 里面叫做 phase2alg，在 strongswan 里面叫做 esp。注意這里要配置內(nèi)核支持的算法。一旦兩端協(xié)商完畢，新的 SA 就會(huì)創(chuàng)建，新連接的數(shù)據(jù)包的 SPI 就會(huì)該 SA，從而實(shí)現(xiàn)對(duì)數(shù)據(jù)的保護(hù)。
對(duì)于具體連接 SA 協(xié)商而言，在 strongswan 里面是通過 leftsubnet, rightsubnet 來定義的，其定義了哪些連接要由 IPsec 來保護(hù)，來封裝。這個(gè)規(guī)則在 IPsec 規(guī)范里面叫做 Traffic Selectors，簡(jiǎn)寫為 TS，發(fā)起方和接收方各稱為 TSi，TSr。如果是 IKEv2 的情況下，遇到 TS_UNACCEPTABLE 的錯(cuò)誤，那么往往是兩端允許的網(wǎng)段配置不一致，需要雙方技術(shù)人員協(xié)商解決。Juniper 設(shè)備如果在基于路由的 IPsec 下，TS是通過 proxy-id 來配置，如果是在基于策略的 IPsec 下，則是通過策略來配置。詳細(xì)參考相關(guān)文檔。
在 linux 下面，可以通過 ip xfrm state, ip xfrm policy 以及 strongswan 的 ipsec statusall 等命令來查看 IPsec 的狀態(tài)。
在網(wǎng)絡(luò)層面，實(shí)際上 IKE 是工作在 UDP 協(xié)議上的，端口 500 或者 4500. 而 IPsec ESP 默認(rèn)工作在 IP 協(xié)議（協(xié)議號(hào)50）上，在需要經(jīng)過 NAT 的情況下，該數(shù)據(jù)包會(huì)被封裝在 UDP 包里面，通過端口 4500 進(jìn)行收發(fā)。所以 4500 端口會(huì)混合著各路 IPsec 數(shù)據(jù)包以及 IKE 的包。感覺比較混亂。
