介紹GRE隧道與IPSec加密相結合問題，熟練掌握下面涉及到的IPSec加密知識，你就會更輕松的選擇自己喜歡的方式來做好IPSec加密的工作。很多方法都會使你豁然開朗的。

IPSec加密網絡的拓撲可以是星形結構（hub−and−spoke）也可以是網狀結構（full mesh）。實際應用中，數據流量主要分布在分支與中心之間，分支與分支之間的流量分布較少，所以星形結構（hub−and−spoke）通常是最常用的，并且它更經濟。因為星形結構（hub−and−spoke）比網狀結構（full mesh）使用更少的點到點鏈路，可以減少線路費用。

在星形拓撲中，分支機構到分支機構（spoke −to−spoke）的連通不需要額外的通訊費用。但在星形結構中，分支到分支的通信必須跨越中心，這會耗費中心的資源并引入延時。

尤其在用IPSec加密時，中心需要在發送數據分支的隧道上解密，而在接收數據的分支隧道上重新加密。還有一種情況是：通訊的兩個分支在同一個城市，而中心在另一個城市，這便引入了不必要的延時。

當星形IPSec網絡（hub−and−spoke）規模不斷擴展時，傳統VPN的配置則愈加繁瑣，且不便于維護和排錯。因此IP數據包的動態路由將非常有意義。但IPSec隧道和動態路由協議之間存在一個基礎問題，動態路由協議依賴于多播或廣播包進行路由更新，而IPSec隧道不支持多播或廣播包的加密。

這里便引入了動態多點VPN （DMVPN）的概念。這里將引入兩個協議：GRE 和 NHRP GRE：通用路由封裝。由IETF在RFC 2784中定義。它是一個可在任意一種網絡層協議上封裝任意一個其它網絡層協議的協議。GRE將有效載荷封裝在一個GRE包中，然后再將此GRE包封裝基于實際應用的傳輸協議上進行轉發。（我覺得：GRE類似木馬的殼。^_^）

IPSec不支持廣播和組播傳輸，可是GRE能很好的支持運載廣播和組播包到對端，并且GRE隧道的數據包是單播的。這就意味著GRE隧道的數據包是可被IPSec加密的，也即GRE Over IPSec。

通過GRE隧道與IPSec加密相結合，利用動態路由協議在加密隧道兩端的路由器上更新路由表。從隧道對端學到的子網在路由表條目里將會包含隧道對端的IP地址作為到達對端子網的下一跳地址。這樣，隧道任何一端的網絡發生變化，另外一端都會動態地學習到這個變化，并保持網絡的連通性而無需改變路由器的配置。

IPSec利用訪問控制列表（ACL）來匹配感興趣數據流。當有數據包匹配所定義的ACL時，IPSec加密隧道便會建立。當利用GRE Over IPSec時，GRE隧道的配置已經包括了GRE隧道對端的地址，這個地址同時也是IPSec隧道的對端地址。所以，沒有必要再單獨為IPSec定義匹配ACL。

通過將GRE隧道與IPSec綁定，GRE隧道一旦建立，將立刻觸發IPSec加密。在用IPSec對GRE包進行加密時，可以將IPSec配置為傳輸模式，因為GRE已經將原始數據包封裝為單播的IP包，沒必要讓IPSec再封裝一個包頭。

GRE的特點使得IPSec加密也能時髦的運行動態協議了。至此，IPSec加密不支持動態路由的歷史改變了，DMVPN中的“多點” 被擺平接下來，讓我們看看“動態”的特性是怎樣被引入的。GRE建立了隧道，IPSec加密完成了VPN網絡的加密部分。想要建立GRE隧道，隧道的一端必須知道另一端的IP地址，并且必須能夠在Internet上路由。這就要求中心和所有分支路由器必須具有靜態的公共IP地址。

可是向ISP申請靜態IP地址的費用是非常昂貴的。通常，為節約地址資源并提高有效利用率，無論是ADSL還是直接線纜接入，ISP會通過DHCP服務來提供動態IP地址。（注：IPv4的瓶頸引發的地址匱乏。IPv6不會存在該問題，號稱可以給地球上的每一粒沙子都分個IP，口氣很大的說）

顯然，GRE+IPSec需要明確知道隧道兩端的IP地址，而分支路由器外網接口的IP地址由其本地ISP動態分配，每次撥入網絡的IP地址是不同的。GRE隧道沒辦法建立，那么VPN還是無法工作。這樣，NHRP在釣足大家胃口之時，應市場需求，在萬眾期盼的目光中閃亮登場了，給它些掌聲樂樂。噼里啪啦。