IPSec-VPN中隧道模式和傳輸模式區(qū)別

SitetoSite互聯(lián)網(wǎng)的3個不同的地方，各使用一個商務(wù)領(lǐng)航網(wǎng)關(guān)相互建立VPN隧道，企業(yè)網(wǎng)(若干PC)之間的數(shù)會話保護，而不是網(wǎng)關(guān)。，具體由兩類協(xié)議組成：來源確認、防重放等安全特性；AH常用摘要算法(單向Hash函數(shù))MD5和SHA1實現(xiàn)該1/8提供數(shù)據(jù)加密；其次AH因為提供數(shù)據(jù)來源確認(源IP地址一旦改變，AH校驗失敗)，所特性，但是此種方案極其少見。上圖是傳輸模式的封裝結(jié)構(gòu)，再來對比一下隧道模式：2/8可以發(fā)現(xiàn)傳輸模式和隧道模式的區(qū)別：從上圖我們還可以驗證上一節(jié)所介紹AH和ESP的差別。下圖是對傳輸模式、隧道模式適用于何種場景的說明。3/81.隧道模式可以適用于任何場景隧道模式雖然可以適用于任何場景，但是隧道模式需要多一層IP頭(通常為20字節(jié)長度)為了使大家有個更直觀的了解，我們看看下圖，分析一下為何在Site-to-Site場景中只能使4/8PCPC量滿足網(wǎng)關(guān)的興趣流匹配條件，發(fā)起行封裝：3.這個數(shù)據(jù)包發(fā)到互聯(lián)網(wǎng)后，其命運注定是杯具的，為什么這么講，就因為其目的地址是10.1.1.2嗎？這并不是根源，根源在于互聯(lián)網(wǎng)并不會維護企業(yè)網(wǎng)絡(luò)的路由，所以丟棄的4.即使數(shù)據(jù)包沒有在互聯(lián)網(wǎng)中丟棄，并且幸運地抵達了響應(yīng)方網(wǎng)關(guān)，那么我們指望響應(yīng)方網(wǎng)關(guān)進行解密工作嗎？憑什么，的確沒什么好的憑據(jù)，數(shù)據(jù)包的目的地址是網(wǎng)PC的SA。我們利用這個反證法，巧妙地解釋了在Site-to-Site情況下不能使用傳輸模式的原因。并且提出了使用傳輸模式的充要條件：興趣流必須完全在發(fā)起方、響應(yīng)方IP地址圍的流量。比如在圖中，發(fā)起方IP地址為6.24.1.2，響應(yīng)方IP地址為2.17.1.2，那么興趣流可以是源同，對不起，請使用隧道模式。5/8IPSec除了一些協(xié)議原理外，我們更關(guān)注的是協(xié)議中涉與到方案制定的容：流。協(xié)商，觸發(fā)的過程通常是將數(shù)據(jù)包中的源、目的地址、協(xié)議以與源、目的端口號與提前指定的IPSec興趣流匹配模板如ACL進行匹配，如果匹配成功則屬于指定興趣流。指定興趣流案過程中，通常會設(shè)計成發(fā)起方指定興趣流屬于協(xié)商興趣流。c定興趣流，也可以不指定(完全由發(fā)起方指定)。P的組合方式與各自使用的算法，還包括興趣流、封裝模式等。5.SA：發(fā)起方、響應(yīng)方協(xié)商的結(jié)果就是曝光率很高的SA，SA通常是包括密鑰與密鑰生存期、算法、封裝模式、發(fā)起方、響應(yīng)方地址、興趣流等容。6/8IPSecIPSec協(xié)商過程，在方案2.滿足興趣流條件，在轉(zhuǎn)發(fā)接口上檢查SA不存在、過期或不可用，都會進行協(xié)商，3.協(xié)商的過程通常分為兩個階段，第一階段是為第二階段服務(wù)，第二階段是真正的為興趣流服務(wù)的SA，兩個階段協(xié)商的側(cè)重有所不同，第一階段主要確認雙方身份的正確性，第二階段則是為興趣流創(chuàng)建一個指定的安全套件，其最顯著的結(jié)果就是第二階段中的興趣流密文。7/8響應(yīng)放到發(fā)起方SA是單獨協(xié)商的，這樣做的好