【正文】 隧道模式的 AH； ? 傳輸模式的 ESP； ? 隧道模式的 ESP。 ? AH 對 IP 層的數(shù)據(jù)使用的 HMAC算法，從而使得對 IP包的修改可以被檢測出來 ? 通過 HMAC算法可以檢測出對 IP包的任何修改，不僅包括對IP包的源 /目的 IP地址的修改，還包括對 IP包載荷的修改，從而保證了 IP包內(nèi)容的完整性 和 IP包來源的可靠性 。 AH頭部格式（續(xù)） ? 4） SPI（ Security Parameter Index） ? SPI是一個(gè) 32位整數(shù)，與源 /目的 IP地址、 IPSec協(xié)議一起組成的三元組可以為該 IP包惟一地確定一個(gè) SA。 AH的傳輸模式 ? 在傳輸模式中， AH插入到 IP頭部（包括 IP選項(xiàng)字段）之后 ， 傳輸層協(xié)議（ TCP、 UDP）或其他 IPSec協(xié)議之前 。 TCP下的 AH的隧道模式 外部 IP頭 內(nèi) 部 IP頭 AH隧道 模式 的例子 I n t e r n e t安 全 網(wǎng) 關(guān) 1 安 全 網(wǎng) 關(guān) 22 2 . 1 3 . 2 . 5 92 7 . 1 6 8 . 3 . 6 01 1 . 1 4 3 . 1 . 2 5 46 3 . 1 6 8 . 2 . 2 5 46 3 . 1 6 8 . 2 / 2 41 1 . 1 4 3 . 1 / 2 41 1 . 1 4 3 . 1 . 16 3 . 1 6 8 . 2 . 1主 機(jī) 2 1主 機(jī) 1 1A H 隧 道 AH AH 內(nèi)部頭 通信終點(diǎn) 內(nèi)部頭 通信終點(diǎn) 外部頭 IPSec終點(diǎn) 外部頭 IPSec終點(diǎn) 網(wǎng)關(guān)到網(wǎng)關(guān)安全性 內(nèi)網(wǎng)無安全 保護(hù) AH隧道模式的優(yōu)缺點(diǎn) ? 優(yōu)點(diǎn) ? 子網(wǎng)所有主機(jī)都可透明享受安全網(wǎng)關(guān)提供的安全保護(hù)； ? 子網(wǎng)內(nèi)部可使用私有 IP地址，無須公有 IP地址； ? 子網(wǎng)內(nèi)部的拓?fù)浣Y(jié)構(gòu)被保護(hù)。 ? 這些不變的部分包括如下： ? IP頭部的字段 ，包括：版本字段、頭部長度字段、 IP總長字段、 ID字段、協(xié)議字段、源地址、目的地址； ? AH頭中除“驗(yàn)證數(shù)據(jù)” （ ICV）以外的其他字段。 AH的反重放機(jī)制（續(xù)） ? 當(dāng) AH收到一個(gè)分組時(shí)，按照如下步驟進(jìn)行進(jìn)入處理： ? 如果收到的分組落在窗口之內(nèi)并且是新的，就進(jìn)行 MAC檢查，如果通過鑒別，就對窗口的相應(yīng)插槽作標(biāo)記； ? 如果收到的分組落在窗口的右邊并且是新的，就進(jìn)行 MAC檢查，如果通過鑒別，窗口就向前走，使得該序號成為右邊界，并對窗口的相應(yīng)插槽作標(biāo)記； ? 如果收到的分組落在窗口的左邊，或者鑒別失敗，就丟棄該分組。 ? NULL加密算法是指實(shí)際不進(jìn)行加密。 ? SA是單向的，每發(fā)送一個(gè)包，外出 SA的計(jì)數(shù)器增 1；每接收一個(gè)包，進(jìn)入 SA的計(jì)數(shù)器增 1。 ? 下一個(gè)頭（ Next Header） ? 8位字段，指明了封裝在載荷中的數(shù)據(jù)類型，例如 6 表示 TCP數(shù)據(jù)。 ? 數(shù)據(jù)包只有經(jīng)過驗(yàn)證證明該包沒有經(jīng)過任何修改，才會(huì)進(jìn)行后續(xù)處理。 ? 不被加密是因?yàn)槁酚善餍枰@些信息來為其尋找路由； ? 不被驗(yàn)證是為了能適用于 NAT等情況。 ? IKE和 ISAKMP的不同之處在于： IKE真正定義了一個(gè)密鑰交換的過程，而 ISAKMP只是定義了一個(gè)通用的可以被任何密鑰交換協(xié)議使用的框架。 ? ISAKMP雙方交換的內(nèi)容稱為載荷（ payload），這些載荷按照某種規(guī)則“疊放”在一起，然后在最前面添加上 ISAKMP頭部，這樣就組成了一個(gè) ISAKMP報(bào)文。 TCP下 ESP隧道模式 ESP隧道 模式 的例子 I n t e r n e t安 全 網(wǎng) 關(guān) 1 安 全 網(wǎng) 關(guān) 22 2 . 1 3 . 2 . 5 92 7 . 1 6 8 . 3 . 6 01 1 . 1 4 3 . 1 . 2 5 46 3 . 1 6 8 . 2 . 2 5 46 3 . 1 6 8 . 2 / 2 41 1 . 1 4 3 . 1 / 2 41 1 . 1 4 3 . 1 . 16 3 . 1 6 8 . 2 . 1主 機(jī) 2 1主 機(jī) 1 1E S P 隧 道 E S P E S P ESP隧道模式的特點(diǎn) ? 在隧道模式下，有兩個(gè) IP頭部： ? 里面的 IP頭部是原始的 IP頭部，含有真實(shí)的源 IP地址、最終的目的 IP地址（ 可以是保留地址 ）； ? 外面的 IP頭部可以包含與里面 IP頭部不同的 IP地址。序號字段不會(huì)泄漏明文中的任何機(jī)密，沒有必要加密。 ? 填充（ Padding） ? 填充字段包含了填充位。 ? 序列號（ Sequence Number） ? 序列號是一個(gè) 32位整數(shù)，作為一個(gè)單調(diào)遞增的計(jì)數(shù)器，為每個(gè) ESP包賦予一個(gè)序號。 ? NULL認(rèn)證算法是指實(shí)際不進(jìn)行認(rèn)證。 AH的反重放機(jī)制（續(xù)） ? 由于 IP本身是 無連接、不可靠的服務(wù) ，協(xié)議不能保證分組的按序到達(dá)，因此， IPSec規(guī)定接收者應(yīng)該實(shí)現(xiàn)大小為 W（默認(rèn) W=64）的窗口。 ? 另外， ICV字段本身在計(jì)算之前也要用 0 填充，計(jì)算之后再填充驗(yàn)證結(jié)果。 ? 隧道模式下， AH驗(yàn)證的范圍也是整個(gè) IP包，因此上面討論的 AH和 NAT的沖突在隧道模式下也存在。 ? 該字段必須為 32位的整數(shù)倍，如果 ICV不是 32位的整數(shù)倍，必須進(jìn)行填充。 ? 2）載荷長度（ Payload Length） ? 接下來的 8位，其值是以 32位（ 4字節(jié)）為單位的整個(gè) AH數(shù)據(jù)（包括頭部和變長的認(rèn)證數(shù)據(jù)）的長度再減 2。 外部 IP ESP 內(nèi)部 IP+TCP ESP隧道模式 IPSec隧道模式下的報(bào)文格式的修改 1 75 05 144U D P 頭 + U D P 數(shù) 據(jù)T C P 頭 + T C P 數(shù) 據(jù)新 I P 頭46① A H 頭5 1② E S P 頭② E S P 頭③ A H 頭5 04舊 I P 頭協(xié)議類 型字段 協(xié)議類 型字段 IPSec的 AH協(xié)議 ? AH— Authentication Header（驗(yàn)證頭部協(xié)議） ? 由 RFC2402定義，是用于增強(qiáng) IP層安全的一個(gè) IPSec協(xié)議。對于外出流量，如果該 SA尚不存在，則啟動(dòng) IKE進(jìn)行協(xié)商，把協(xié)商的結(jié)果連接到該安全策略上。 ? 9） PMTU：所考察的路徑的 MTU及其 TTL變量。 ? 該窗口僅用于進(jìn)入數(shù)據(jù)包，如接收方不選擇抗重放服務(wù)（如手工設(shè)置 SA時(shí)），則不用抗重放窗口。 ? 對于外出的流量，如果需要使用 IPSec處理，然而相應(yīng)的 SA不存在，則 IPSec將啟動(dòng) IKE來協(xié)商出一個(gè) SA，并存儲(chǔ)到 SAD中。 ? 2）通過 IKE自動(dòng)管理： ? SA的自動(dòng)建立和動(dòng)態(tài)維護(hù)一般通過 IKE 協(xié)議進(jìn)行。 ? 保證數(shù)據(jù)機(jī)密性 ? IPSec通過加密算法使只有真正的接收方才能獲取真正的發(fā)送內(nèi)容，而他人無法獲知數(shù)據(jù)的真正內(nèi)容。 IPSec要解決的主要安全問題（續(xù)） ? 2） 篡改： ? 攻擊者可以在通信線路上非法竊取到 IP數(shù)據(jù)包，修改其內(nèi)容并重新計(jì)算校驗(yàn)和，數(shù)據(jù)包的接收方一般不可能察覺出來。 ? 由 IPSec提供用戶數(shù)據(jù)的加密，從而給用戶提供更好的安全性。 ? 在 2023年， Cisco等公司又對 GRE協(xié)議進(jìn)行了修訂（ GRE V2），標(biāo)號為 RFC 2784。 ? 5）處理 UDP報(bào)頭并將數(shù)據(jù)報(bào)提交給 L2TP協(xié)議。 ? 2） UDP封裝 ： L2TP幀進(jìn)一步添加 UDP報(bào)頭進(jìn)行 UDP封裝，在UDP報(bào)頭中，源端和目的端端口號均為 1701。 L2TP隧道的建立過程 L2TP協(xié)議報(bào)文 ? L2TP客戶端和服務(wù)器之間的報(bào)文也有兩種：控制報(bào)文 和 數(shù)據(jù)報(bào)文， 這兩種報(bào)文均采用UDP協(xié)議封裝和傳送 PPP幀。 ? L2TP協(xié)議支持 IP、 、幀中繼或 ATM等作為傳輸協(xié)議，但目前僅定義了基于 IP網(wǎng)絡(luò)的 L2TP。 ? 在創(chuàng)建基于 PPTP的 VPN連接過程中，使用的認(rèn)證機(jī)制與創(chuàng)建 PPP連接時(shí)相同，主要有 EAP、 MSCHAP、CHAP、 SPAP和 PAP。 三、第二層隧道協(xié)議 — PP2P和 L2TP ? 第二層隧道協(xié)議用于傳輸 第二層網(wǎng)絡(luò)協(xié)議 ，它主要應(yīng)用于 構(gòu)建 Access VPN。 ? 客戶計(jì)算機(jī)上必須安裝有隧道客戶軟件。 ? 典型的傳輸協(xié)議仍然是 IP。 隧道技術(shù) ? 隧道 ? 所謂“隧道”就是一種 封裝技術(shù) ，它利用一種網(wǎng)絡(luò)傳輸協(xié)議，將 其他協(xié)議 產(chǎn)生的數(shù)據(jù)報(bào)文封裝在它自己的報(bào)文中在網(wǎng)絡(luò)中傳輸。 CHAP ? CHAP是一種基于散列函數(shù)的認(rèn)證協(xié)議，見 RFC1994。 ? 如果采用 VPN，只是在結(jié)點(diǎn)處架設(shè) VPN設(shè)備，就可以利用 Inter建立安全連接，如果有新的內(nèi)部網(wǎng)絡(luò)想加入安全連接，只需添加一臺(tái) VPN設(shè)備，改變相關(guān)配置即可。 Intra VPN ? 如果要進(jìn)行企業(yè)內(nèi)部異地分支機(jī)構(gòu)之間的互聯(lián)，可以使用 Intra VPN，即 網(wǎng)關(guān)對網(wǎng)關(guān) VPN。 Virtual、 Private、 Network（續(xù)） ? Private ? 表示 VPN是被特定企業(yè)或用戶私有的，并不是任何公共網(wǎng)絡(luò)上的用戶都能夠使用已經(jīng)建立的 VPN通道，而是只有經(jīng)過授權(quán)的用戶才能使用。 ? VPN是將物理上分布在不同地點(diǎn)的網(wǎng)絡(luò)通過公用骨干網(wǎng)（尤其是 Inter）連接而成的 邏輯上的虛擬子網(wǎng) 。 VPN的類型 ? VPN主要有三種類型： ? Access VPN：遠(yuǎn)程訪問 VPN； ? Intra VPN：企業(yè)內(nèi)部 VPN； ? Extra VPN：企業(yè)擴(kuò)展 VPN。 Intra VPN（續(xù)） 總 部分 部網(wǎng) 關(guān) 網(wǎng) 關(guān)I n t e r n e t內(nèi)部 IP，如： 內(nèi)部 IP，如： 好像可 直接 通過內(nèi)部 IP通信 公網(wǎng) IP 公網(wǎng) IP 采用隧道協(xié)議 （如 IP over IP） 進(jìn)行傳輸，用 公網(wǎng) IP報(bào)文承載 內(nèi)部 IP報(bào)文 Extra VPN ? 如果企業(yè)希望將客戶、供應(yīng)商、合作伙伴連接到企業(yè)內(nèi)部網(wǎng)，可以使用 Extra VPN。 二、 VPN技術(shù) ? 密碼技術(shù) ? 身份認(rèn)證技術(shù) ? 隧道技術(shù) ? 密鑰管理技術(shù) 密碼技術(shù) ? VPN利用 Inter的基礎(chǔ)設(shè)施傳輸企業(yè)私有的信息，因此傳遞的數(shù)據(jù)必須經(jīng)過加密，從而確保網(wǎng)絡(luò)上未授權(quán)的用戶無法讀取該信息。 U— 〉 AS： H (PW || R) 用戶輸入 口令 PW 并計(jì)算 H (PW || R)，然后將 H (PW || R)作為應(yīng)答信息傳給認(rèn)證服務(wù)器。 隧道協(xié)議 ? 任何隧道協(xié)議的數(shù)據(jù)包格式都是由 乘客協(xié)議 、 封裝協(xié)議 和 傳輸協(xié)議 三部分組成。