一直以來汗牛充棟的文章和資料都在大談特談Open×××或者其它的使用SSL協定的SSL×××多麼的好，多麼的比IPSec靈活，這使得IPSec漸漸淡出了普通人民的視線，成了核心網以及超高端裝置的專用×××。
如果要開發一個×××産品，Open×××就好像一個各地百腦彙商場外面站立的那些拉客人員一樣，把大家紛紛引來，而IPSec就像淮海路奢侈品專賣店一樣，以高端，花費大，維護難等總之不是什麼好聽的話為理由而被拒絕。本文從最基本的幾點來說明IPSec并不是那麼的笨拙，很多靈活性是諸如Open×××之類的草根×××所無法做到的。
1.IPSec由各種構件組成
IPSec并不是一個整體的結構，IPSec是由一整套的構件所構成的，這些構件部分是可以替換的，這些構件包括：
安全通道支援協定：IKE，ISAKMP...
可以使用不同的認證方式進行接入節點的認證。雖然無法直接使用被WEB用瘋了的SSL協定，但是IKE并不比它差，此時我們完全沒有必要用SSL協定在WEB領域的表現來為之加分，因為我們現在讨論的是×××，而×××是一個二層或者三層的概念，和WEB風馬牛不相及。SSL使用了PKI核心，IKE也可以使用這些PKI元件，實際上基于X.509的認證方式在IKE中早已成了一個重要的組成部分。
隧道加密方式：傳輸ESP，隧道ESP，傳輸AH，隧道AH
傳輸模式的IPSec為端到端控制提供了很好的支援，這種模式下，IPSec除了加密或者認證之外并不對資料包進行任何封裝，而隧道模式則為站到站的資料保護提供了很好的支援。而Open×××隻是一個隧道模式，它是無條件封裝的，端到端的可擴充性很差，比如Open×××面對強主機模式的Windows且還要認證源IP時就會心有餘而力不足。
資料結構：SPD，SADB
這些資料結構是IPSec進行加密抉擇時使用的重要證據，類似Open×××的路由表，Open×××隻能以标準路由的方式将加密資料進行識别，如果要想通過的别的方式，必須在路由的前端增加其它識别方式，比如對于Liunx則需要在PREROUTING這個HOOK上為資料包打mark，然後将特定mark的資料包定向到某一個政策路由表，最終還是統一到路由。而IPSec的這些資料結構獨立于IPSec加密以及秘要協商，可以以任何方式生成，并且可以以任何方式分發到任何裝置，對于實作也更靈活，可以針對比對資料庫的包直接進行IPSec操作，這無疑提高了效率，也可以和其它的協定棧元件進行接口，見下節。
和其它協定棧構件的接口：和GRE的接口，和VTI的接口
如果你覺得Open×××使用統一的路由接口截獲感興趣包是一大優勢的話(說實話，我也一直都這麼認為，然而當你面對幾百條隧道的時候，你可真的要晚上睡不着覺了，而我雖然還沒有面對，卻已經有臨危的感覺了)，那也隻是面對小型網絡，如果面對成百上千的網段的話，更可惡的是這些網段路由還不能彙聚的情況下，路由就不妥了，不考慮路由表龐大的問題(如今高速硬體足以面對這種境況)，單單考慮維護人員的工作量就夠你喝一壺的了。不管怎樣，路由的方式是網管最熟悉的方式，有多種方式配置路由表，如果能将路由配置的靈活性和路由管理的便捷性結合的話就能克服Open×××的上述缺點，幸運的是IPSec和GRE結合就可以做到這一點。GRE是另一種技術，可以把路由管理的工作交給GRE來完成，IPSec隻完成安全政策的維護即可，這是Open×××所做不到的。
以上如此豐富的可替換構件足以證明IPSec足夠靈活，可以組織成各種複雜的×××拓撲進而滿足各種需求。Open×××的非元件化使得Open×××隻能依賴其自身的特性，對外的接口充其量也就是一些事件接口，IPSec自身本來就是元件化的。
2.IPSec動态建立隧道，Open×××則不行
衆所周知的一個特性就是IPSec可以動态建立隧道，資料包到來，如果發現隧道還沒有建立好，則需要進行IKE協商，協商完成之前，所有的資料都要排隊或者隊列滿後被丢棄，這是Open×××所做不到的，Open×××使用使用者态的socket連接配接來建立隧道，對于隧道用戶端，虛拟網卡和路由依賴于socket連接配接的建立，即使通過修改Open×××代碼做到虛拟網卡在socket連接配接建立之前建立，也無法獲知其IP位址進而建立路由表，對于服務端，所有的socket連接配接在Open×××的打開檔案描述符中被維護，資料包路由到虛拟網卡後并不知道某條特定隧道是否可用，是以資料包會進入一個黑洞。
IPSec可以動态建立隧道，這是因為隧道的建立以及安全政策并不依賴任何socket連接配接或者其它網絡連接配接，隧道狀态和政策存在與否并不關聯，一切都是SADB和PDB決定的，這些資料庫和網絡沒有關系，資料包隻要比對到資料庫中的條目，就會被加密，在被加密前需要懶惰建立隧道，如果隧道沒有建立，那麼就需要先進性IKE協商。
3.IPSec可以很靈活的實作高可用性和負載均衡
Open×××實作熱備是很麻煩的，實作負載均衡幾乎是不可能的，除非分割網段，然而這些對于IPSec卻是小菜一碟，一切盡在SADB和PDB，這些純資料可以被傳輸，可以同步到任何一台機器上，是以任何一台機器都可以接管目前的IPSec而無需面對使用者斷線的困擾。Open×××是無法進行資料同步的，因為這些資料是和程序高度相關的，而程序的資料字段又是不能跨越機器的，除非深拷貝所有的資料，然而跨機器深拷貝程序本身就是一個極富挑戰性的工作。
4.IPSec并不是穿越不了NAT
網絡的本質就是某種封裝，隧道是一個同再層封裝或者上層逆封裝，資料其實可以被任意的封裝。IPSec之是以無法穿越NAT是因為四層校驗僞頭的問題，如果将所有資料進行再封裝，則完全可以繞開這個問題，是以我們可以使用UDP隧道，該UDP隧道對資料不進行校驗(UDP可以選擇不校驗)，一旦檢測到兩個×××節點之間有NAT，則兩個節點在傳輸隧道資料時使用不校驗的UDP将資料再次封裝(其實檢驗也沒有問題，這主要是為了效率)，資料流的5元組資訊全部在IKE協商階段确定，唯一需要注意的是，NAT後面的×××節點一定要作為IKE的發起方，否則就需要面對UDO打洞的問題了。IKE建立之後，得到各自的5元組，然後偷梁換柱，将此五元組用來封裝UDP資料即可。(本節的前置知識：IKE使用UDP進行協商)。
5.IPSec和GRE的合力其實就是Open×××
你會發現，IPSec和GRE合起來就是Open×××，隻是它在核心态實作。GRE建立一個虛拟的網卡，通過路由将感興趣包路由到該虛拟網卡，然後在該虛拟網卡上應用IPSec政策，所有從該網卡傳輸的資料都要被加密，所有從該網卡接收的資料都要被解密，這難道不就是Open×××的思想嗎？IPSec雖然在配置上是對等的，實際上還是有一個發起者，資料通信沒有一個發起者能行嗎？？
6.解困
從作業系統概念和系統維護的角度，能在使用者态實作的就不在核心态實作，這是因為使用者态的API遠比核心态的更加統一，舉一個最簡單的例子，各種作業系統都實作了伯克利套接字，且接口一緻，可是在作業系統核心層面，各家實作卻是大相徑庭。這也許就是Open×××比IPSec更有優勢的原因。然而從軟體工程上考慮，IPSec的可替換組建化設計更符合軟體工程的高内聚低耦合的原則，難道僅僅因為可怖的作業系統核心協定棧的複雜性就抛棄它嗎？真心希望使用者态的協定棧實作。具有諷刺意義的是，很多嵌入式系統，其協定棧真的就是在使用者态實作的，有的嵌入式系統根本就不區分核心态和使用者态，這種系統下Open×××和IPSec孰優孰劣呢？
![網絡基礎知識（IP資料封包結構）三[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)