數據包結構分析

通過wireshark抓取在不同鏈路上的數據包，分析數據在網上傳輸過程。首先要有下面基礎知識。
1,網絡數據封裝過程，數據包發送的時候從上往下封裝的，解封裝反過來。

從下往上看
最下面是以太網幀，位於osi參考模型的數據鏈路層。該層幀格式有以太網幀（常用），802.2/802.3幀和ppp幀。
 

 
  
對應網絡層，主要協議有ip，ICMP，IGMP。如下面的ip數據包頭

對於傳輸層，主要的協議就是TCP（6）和UDP（17）。
 

 
 
第一個包(udp包)
 

 
 

 
這是有我本機發出的upd包
附ip頭字段說明

版本號（Version）：長度4比特。標識目前採用的IP協議的版本號。一般的值爲0100（IPv4），0110（IPv6）

IP包頭長度（HeaderLength）：長度4比特。這個字段的作用是爲了描述IP包頭的長度，因爲在IP包頭中有變長的可選部分。該部分佔4個bit位，單位爲32bit（4個字節），即本區域值= IP頭部長度（單位爲bit）/(8*4)，因此，一個IP包頭的長度最長爲“1111”，即15*4＝60個字節。IP包頭最小長度爲20字節。

服務類型（Type of Service）：長度8比特。8位 按位被如下定義 PPP D T R C 0
但是TOS字段已經作爲區分服務(Diffsrv)架構一部分被重新定義了，開始的6位構成區分服務代碼點（DiffServ Code Piont，DSCP），利用這6位可以定義64個不同的服務類別。
ECN顯式擁塞通知

IP包總長（Total Length）：長度16比特。 以字節爲單位計算的IP包的長度 (包括頭部和數據)，所以IP包最大長度65535字節。

標識符（Identifier）（數據報ID）:長度16比特。該字段和Flags和Fragment Offest字段聯合使用，對大的上層數據包進行分段（fragment）操作。路由器將一個包拆分後，所有拆分開的小包被標記相同的值，以便目的端設備能夠區分哪個包屬於被拆分開的包的一部分。

標記（Flags）：長度3比特。該字段第一位不使用。第二位是DF（Don't Fragment）位，DF位設爲1時表明路由器不能對該上層數據包分段。如果一個上層數據包無法在不分段的情況下進行轉發，則路由器會丟棄該上層數據包並返回一個錯誤信息。第三位是MF（More Fragments）位，當路由器對一個上層數據包分段，則路由器會在除了最後一個分段的IP包的包頭中將MF位設爲1。

片偏移（Fragment Offset）：長度13比特。表示該IP包在該組分片包中位置，接收端靠此來組裝還原IP包。

生存時間（TTL）：長度8比特。當IP包進行傳送時，先會對該字段賦予某個特定的值。當IP包經過每一個沿途的路由器的時候，每個沿途的路由器會將IP包的TTL值減少1。如果TTL減少爲0，則該IP包會被丟棄。這個字段可以防止由於路由環路而導致IP包在網絡中不停被轉發。

協議（Protocol）：長度8比特。標識了上層所使用的協議。
以下是比較常用的協議號：
    1    ICMP
    2    IGMP
    6    TCP
   17   UDP
   88   IGRP
   89   OSPF

頭部校驗（Header Checksum）：長度16位。用來做IP頭部的正確性檢測，但不包含數據部分。 因爲每個路由器要改變TTL的值,所以路由器會爲每個通過的數據包重新計算這個值。

起源和目標地址（Source and Destination Addresses）:這兩個地段都是32比特。標識了這個IP包的起源和目標地址。要注意除非使用NAT，否則整個傳輸的過程中，這兩個地址不會改變。

可選項（Options）：這是一個可變長的字段。該字段屬於可選項，主要用於測試，由起源設備根據需要改寫。可選項目包含以下內容：
    鬆散源路由（Loose source routing）：給出一連串路由器接口的IP地址。IP包必須沿着這些IP地址傳送，但是允許在相繼的兩個IP地址之間跳過多個路由器。
    嚴格源路由（Strict source routing）：給出一連串路由器接口的IP地址。IP包必須沿着這些IP地址傳送，如果下一跳不在IP地址表中則表示發生錯誤。
    路由記錄（Record route）：當IP包離開每個路由器的時候記錄路由器的出站接口的IP地址。
    時間戳（Timestamps）：當IP包離開每個路由器的時候記錄時間。

填充（Padding）：因爲IP包頭長度（Header Length）部分的單位爲32bit，所以IP包頭的長度必須爲32bit的整數倍。因此，在可選項後面，IP協議會填充若干個0，以達到32bit的整數倍。

tcp三次握手
附TCP字段

源端口和目的端口字段——各佔 2 字節。端口是傳輸層與應用層的服務接口。傳輸層的複用和分用功能都要通過端口才能實現。

序號字段——佔 4 字節。TCP 連接中傳送的數據流中的每一個字節都編上一個序號。序號字段的值則指的是本報文段所發送的數據的第一個字節的序號。

確認號字段——佔 4 字節，是期望收到對方的下一個報文段的數據的第一個字節的序號。

數據偏移——佔 4  bit，它指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠。“數據偏移”的單位不是字節而是 32 bit 字（4 字節爲計算單位）。

保留字段——佔 6 bit，保留爲今後使用，但目前應置爲 0。

緊急比特 URG —— 當 URG = 1 時，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應儘快傳送(相當於高優先級的數據)。
確認比特 ACK —— 只有當 ACK = 1 時確認號字段纔有效。當 ACK = 0 時，確認號無效。
推送比特 PSH (Push) —— 接收 TCP 收到推送比特置 1 的報文段，就儘快地交付給接收應用進程，而不再等到整個緩存都填滿了後再向上交付。
復位比特 RST (ReSet) —— 當 RST = 1 時，表明 TCP 連接中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立傳輸連接。
同步比特 SYN —— 同步比特 SYN 置爲 1，就表示這是一個連接請求或連接接受報文。
終止比特 FIN (Final) —— 用來釋放一個連接。當FIN = 1 時，表明此報文段的發送端的數據已發送完畢，並要求釋放運輸連接。

窗口字段 —— 佔 2 字節。窗口字段用來控制對方發送的數據量，單位爲字節。TCP
連接的一端根據設置的緩存空間大小確定自己的接收窗口大小，然後通知對方以確定對方的發送窗口的上限。

檢驗和 —— 佔 2 字節。檢驗和字段檢驗的範圍包括首部和數據這兩部分。在計算檢驗和時，要在 TCP 報文段的前面加上 12 字節的僞首部。

緊急指針字段 —— 佔 16 bit。緊急指針指出在本報文段中的緊急數據的最後一個字節的序號。

選項字段 —— 長度可變。TCP最常用的選項字段是MSS(Maximum Segment Size)，即最大報文段長度 MSS 告訴對方 TCP：“我的緩存所能接收的報文段的數據字段的最大長度是 MSS 個字節。填充字段 —— 這是爲了使整個首部長度是 4 字節的整數倍。

 

 
 

 

 

 

到這三次握手的過程就結束了，下面就開始數據傳輸。
pptp包
首先要知道ppp鏈路協議，其幀格式如下

每一幀都以標誌字符0 x 7 e開始和結束。緊接着是一個地址(A)字節，值始終是0 x ff，然後是一個值爲0 x 0 3的控制(C)字節。
協議的兩個字段，表示後面信息部分的數據協議是什麼，包括：
 0x0021——信息字段是IP數據報
 0xC021——信息字段是鏈路控制數據LCP
 0x8021——信息字段是網絡控制數據NCP
 0xC023——信息字段是安全性認證PAP
 0xC025——信息字段是LQR
 0xC223——信息字段是安全性認證CHAP

PPP協議中提供了一整套方案來解決鏈路建立、維護、拆除、上層協議協商、認證等問題。具體包含這樣幾個部分：鏈路控制協議LCP（Link Control Protocol）；網絡控制協議NCP（Network Control Protocol）；認證協議，最常用的包括口令驗證協議PAP（Password Authentication Protocol）和挑戰握手驗證協議CHAP（Challenge-Handshake Authentication Protocol）。
典型的PPP鏈路協商過程分爲三個階段：鏈路建立階段、認證階段（可選）、網絡控制協商階段。PPP的協商過程主要經過如下圖所示五個狀態：
    鏈路死亡狀態（Dead）——鏈路一定開始和結束於這個狀態。當一個外部事件（例如載波偵聽或網絡管理員設定）指出物理層已經準備就緒時，PPP將進入鏈路建立階段。

    鏈路建立狀態(Establish)——在這個狀態PPP通過發送和接收鏈路配置報文（Configuration），協商具體的參數選項，當收到併發送Configurations ACK後，該狀態結束，即打開鏈路。如果線路中斷或者配置失效將返回鏈路死亡狀態
    認證狀態(Authenticate)——在這個狀態協商具體的認證參數，是否認證？進行什麼認證？認證的參數交換等，當認證通過或不需認證將開始網絡層協議的協商，進入網絡層協議配置狀態，否則鏈路終止，最後回到鏈路死亡階段
    網絡層協議配置狀態(Network)——LCP協商成功將進入NCP的協商階段，在這個階段將進行網絡層協議的協商，每一種網絡層協議（如IP、IPX或AppleTalk）需要單獨建立和配置一個NCP，如果任一的NCP協商不成功將隨時關閉該NCP。NCP協商通後將可以進行網絡報文的通信。如果不成功將關閉鏈路並進入鏈路終止狀態，最後返回初始的鏈路死亡狀態
    鏈路終止狀態(Terminate)——因爲鏈路失效、認證失敗、鏈路質量狀態失敗、鏈路空閒時間超時以及管理員關閉鏈路等原因，可隨時進入鏈路終止狀態。PPP協議通過發送Terminate-Request並接收到Terminate-ACK以後進入該狀態
LCP(鏈路控制協議)
    配置、建立、維護和測試數據鏈路的連接，有如下協商參數：
    1 Maximum-Receive-Unit（最大接收單元）
    3 Authentication-Protocol（認證協議）
    4 Quality-Protocol（質量協議）
    5 Magic-Number（魔術數）
    7 Protocol-Field-Compression（協議域壓縮）
    8 Address-and-Control-Field-Compression（地址和控制域壓縮）
    身份認證、壓縮、多鏈路綁定、回撥等功能均在LCP子層實現。
NCP(網絡控制協議)
    建立和配置不同的網絡層協議，比如選擇IPCP，協商IP及IP數據壓縮等。IP地址協商就是在這層實現。

 
現在可以看pptp連接過程

 

PPTP控制連接通過以下步驟建立：
   TCP連接由PPTP客戶機上的一個動態分配的TCP端口到PPTP服務器上的TCP端口1723建立一個連接（三次握手）。
   PPTP客戶端發送一條PPTP Start-Control-Connection-Request（開始控制連接請求）消息，後者將用於建立一個PPTP控制連接。
   PPTP服務器使用一條PPTP Start-Control-Connection-Reply（開始控制連接應答）消息予以響應。
   PPTP客戶端發送一條PPTP Outgoing-Call-Request（傳出調用請求）消息，並選擇一個調用ID，識別用於將數據從PPTP客戶端發送到PPTP服務器的PPTP隧道。PPTP客戶端使用PPTP
Outgoing-Call-Request消息從PPTP服務器請求一個PPTP隧道（也稱爲調用）。
   PPTP服務器發送一條PPTP Outgoing-Call-Reply（傳出調用應答）消息，並選擇自身的調用ID，識別將數據從PPTP服務器發送到PPTP客戶端的PPTP隧道。
   PPTP客戶端發送一條PPTP Set-Link-Info（設置鏈路信息）消息來指定PPTP協商選項。

PPTP控制連接創建過程的最終結果如下：
   PPTP服務器已允許創建一個PPTP隧道。
   PPTP客戶端已確定了在通過PPTP隧道向PPTP服務器發送數據時在GRE報頭中使用的調用ID。
   PPTP服務器已確定了在通過PPTP隧道向PPTP客戶端發送數據時在GRE報頭中使用的調用ID。

在建立PPTP控制連接之後，數據就可以在PPTP客戶端和PPTP服務器之間發送了。 通過PPTP連接發送的第一個數據包將用於建立PPP連接。
數據包首先被加密並使用一個PPP報頭進行封裝。 所得到PPP幀將使用一個通用路由封裝（GRE）報頭進行封裝，該報頭已針對PPTP修改過。 然後，GRE封裝的PPP幀使用一個IP報頭進行封裝，這個報頭包含對應於PPTP隧道端點的源和目標IP地址。

爲了維持PPTP控制連接，PPTP客戶端每隔60秒發送一條PPTP Echo Request（回送請求）消息，不管PPTP客戶端和服務器之間是否正在發送GRE封裝的數據。在接收到PPTP Echo Request消息時，PPTP服務器將發送一條PPTP Echo Reply（回送應答）消息。PPTP Echo Request消息包含一個Identifier字段，該字段的值將在PPTP Echo Reply消息中回顯，以便PPTP客戶端能夠將PPTP Echo Request與其應答相匹配。

爲了終止PPTP連接，PPP連接、PPTP協議連接和TCP連接必須全部終止。 當PPTP客戶端終止PPTP連接時，將會交換如下數據包：
   PPTP客戶端發送一條PPTP Set-Link-Info消息來指定鏈路的PPP參數。
   PPTP客戶端發送一條Link Control Protocol (LCP) Terminate-Request消息來終止PPP連接。
   PPTP服務器發送一條PPTP Set-Link-Info消息來指定鏈路的PPP參數。
   PPTP服務器發送LCP Terminate-Ack消息來響應LCP Terminate-Request消息，從而終止PPP連接。
   PPTP客戶端發送一條PPTP Clear-Call-Request消息，向PPTP服務器表示PPTP控制連接即將終止。
   PPTP服務器使用一條PPTP Call-Disconnected-Notify消息進行響應。
   PPTP客戶端發送一條PPTP Stop-Control-Connection-Request消息來終止PPTP控制連接.
   PPTP服務器使用一條PPTP Stop-Control-Connection-Reply消息進行響應。
   TCP連接終止。
如果PPTP服務器要終止連接，所交換的消息是相同的，只要將上述過程中的PPTP客戶端替換成了PPTP服務器即可

附GRE報文格式

 

gre報文格式(GRE頭部的長度爲4～20字節)
1,前4 字節是必須出現的
2,第5～20字節將根據第1字節的相關bit位信息，可選出現
3,GRE頭部的長度將影響Tunnel口的mtu值

0bit  C:校驗和標誌位。如配置了checksun則該位置爲1，同時校驗和（可選）、偏離（可選）部分的共4 bytes出現在GRE頭部。
                      如不配置checksun則該位置爲0，同時校驗和（可選）、偏離（可選）部分不出現在GRE頭部。
1bit  R:路由標誌位。  如R爲1，校驗和（可選）、偏離（可選）、路由（可選）部分的共8 bytes出現在GRE頭部。
                      如R爲0, 校驗和（可選）、偏離（可選）、路由（可選）部分不出現在GRE頭部。
2bit  K:密鑰標誌位。  如配置了KEY則該位置爲1，同時密鑰（可選）部分的共4 bytes出現在GRE頭部。
                      如不配置KEY則該位置爲0，同時密鑰（可選）部分不出現在GRE頭部。
3bit  S:序列好同步標誌位。如配置了sequence-datagrams則該位置爲1，同時序列號（可選）部分的共4 bytes出現在GRE頭部。
                          如不配置sequence-datagrams則該位置爲0，同時序列號（可選）部分不出現在GRE頭部。
4bit  s:嚴格源路由標誌位。  除非所有的路由都符合嚴格源路由，該bit位爲1。通常該bit爲0。
5~7bit：遞歸控制：該位置需爲0
8~12bit: 未定義，需爲0
13~15 版本：需爲0
16~31 協議類型：常用的協議，例如IP協議爲0800

針對PPTP修改過的GRE報頭具有如下所示的結構
    0bit  C:校驗和標誌位，對於PPTP，該標誌總被設爲0。
    1bit  R:路由標誌位，對於PPTP，該標誌總被設爲0。
    2bit  K:密鑰標誌位對於PPTP，該標誌總被設爲1。Key字段是Protocol Type、Payload Length和Call ID字段的組合。
    3bit  S:序列好同步標誌位，當設置爲1時，表示提供了Sequence Number字段。
    4bit  s:嚴格源路由標誌位對於PPTP，該標誌總被設置爲0。
    Recursion Control（遞歸控制） 一個用於遞歸的3位標誌，對於PPTP，該字段總被設爲0。
    Flags 一個用於GRE標誌的4位字段。對於PPTP，該字段總被設爲0。
    Version 一個用於表示GRE報頭版本的3位字段。對於PPTP，該字段總被設爲1。
    Protocol Type 一個用於存儲GRE有效負載（payload）的EtherType值的16位字段。對於PPTP，該字段總被設爲0x880B，即PPP幀的EtherType值。
    Call ID 一個用於表示這個包的PPTP隧道的16位字段。對於PPTP連接，Call ID字段有兩個不同的值。 一個值用於PPTP客戶端發送的數據，另一個值用於PPTP服務器發送的數據。
    Sequence Number 一個用於表示這個數據包的序列號的32位字段。該字段僅在Sequence Number Present標誌被設置爲1時才提供。

下面是我通過wiresharke抓的包來驗證

 

 

 
 

 
下面我想總結下openvpn的實現，但是先要了解ssl。
ssl在TCP/IP模型位置如下圖

 
SSL：（Secure Socket Layer，安全套接字層）  ：位於可靠的面向連接的網絡層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通訊。 該協議由兩層組成：SSL記錄協議和ＳＳＬ握手協議。

ssl記錄協議
SSL記錄協議爲SSL連接提供兩種服務：機密性和報文完整性。在SSL協議中，所有的傳輸數據都被封裝在記錄中,記錄是由記錄頭和長度不爲0的記錄數據組成的。所有的SSL通信都使用SSL記錄層，記錄協議封裝上層的握手協議、警告協議、改變密碼格式協議和應用數據協議。其包涵如下字段：

 

內容類型（8位）：封裝的高層協議.已經定義的內容類型是握手協議、警告協議、改變密碼格式協議和應用數據協議.
主要版本（8位）：使用的SSL主要版本.對於SSLv3.0，值爲3.
次要版本（8位）：使用的SSL次要版本.對於SSLv3.0，值爲0.
壓縮長度（16位）：明文數據（如果選用壓縮則是壓縮數據）以字節爲單位的長度.

 

SSL握手協議
SSL握手協議被封裝在記錄協議中，該協議允許服務器與客戶機在應用程序傳輸和接收數據之前互相認證、協商加密算法和密鑰。在初次建立SSL連接時服務器與客戶機交換一系列消息。
SSL握手協議報文頭包括三個字段：
      類型（1字節）：該字段指明使用的SSL握手協議報文類型。SSL握手協議報文包括10種類型。報文類型見下圖。
            長度（3字節）：以字節爲單位的報文長度。
            內容（≥1字節）：使用的報文的有關參數。

 
ssl握手協議協商過程

 

1）建立安全能力。客戶機向服務器發送client_hello報文，服務器向客戶機迴應server_hello報文，建立如下的安全屬性：協議版本，會話ID，密文族，壓縮方法，同時生成並交換用於防止重放攻擊的隨機數。密文族參數包括密鑰交換方法（Deffie-Hellman密鑰交換算法、基於RSA的密鑰交換和另一種實現在Fortezza chip上的密鑰交換）、加密算法（DES、RC4、RC2、3DES等）、MAC算法（MD5或SHA-1）、加密類型（流或分組）等內容。

（2）認證服務器和密鑰交換。在hello報文之後，如果服務器需要被認證，服務器將發送其證書。如果需要，服務器還要發送server_key_exchange。然後，服務器可以向客戶發送certificate_request請求證書。服務器總是發送server_hello_done報文，指示服務器的hello階段結束。

（3）認證客戶和密鑰交換。客戶一旦收到服務器的server_hello_done報文，客戶將檢查服務器證書的合法性（如果服務器要求），如果服務器向客戶請求了證書，客戶必須發送客戶證書，然後發送client_key_exchange報文，報文的內容依賴於client_hello與server_hello定義的密鑰交換的類型。最後，客戶可能發送client__verify 報文來校驗客戶發送的證書，這個報文只能在具有簽名作用的客戶證書之後發送。

（4）結束。客戶發送change_cipher_spec報文並將掛起的CipherSpec複製到當前的CipherSpec。這個報文使用的是改變密碼格式協議。然後，客戶在新的算法、對稱密鑰和MAC祕密之下立即發送finished報文。finished報文驗證密鑰交換和鑑別過程是成功的。服務器對這兩個報文響應，發送自己的change_cipher_spec報文、finished報文。握手結束，客戶與服務器可以發送應用層數據了。 
當客戶從服務器端傳送的證書中獲得相關信息時，需要檢查以下內容來完成對服務器的認證：時間是否在證書的合法期限內；簽發證書的機關是否客戶端信任的；簽發證書的公鑰是否符合簽發者的數字簽名；證書中的服務器域名是否符合服務器自己真正的域名。服務器被驗證成功後，客戶繼續進行握手過程。

SSL報警協議是用來爲對等實體傳遞SSL的相關警告。如果在通信過程中某一方發現任何異常,就需要給對方發送一條警示消息通告。警示消息有兩種：
   Fatal錯誤,如傳遞數據過程中發現錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩衝區相應的會話記錄.
   Warning消息,這種情況,通信雙方通常都只是記錄日誌,而對通信過程不造成任何影.

SSL修改密文協議
爲了保障SSL傳輸過程的安全性,客戶端和服務器雙方應該每隔一段時間改變加密規範。所以有了SSL修改密文協議。SSL修改密文協議是3個高層的特定協議之一,也是其中最簡單的一個。在客服端和服務器完成握手協議之後,它需要向對方發送相關消息(該消息只包含一個值爲1的單字節)，通知對方隨後的數據將用剛剛協商的密碼規範算法和關聯的密鑰處理，並負責協調本方模塊按照協商的算法和密鑰工作.

應用數據協議：將應用數據直接傳遞給記錄協議SSL報警協議是用來爲對等實體傳遞SSL的相關警告。如果在通信過程中某一方發現任何異常,就需要給對方發送一條警示消息通告。警示消息有兩種：
   Fatal錯誤,如傳遞數據過程中發現錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩衝區相應的會話記錄.
   Warning消息,這種情況,通信雙方通常都只是記錄日誌,而對通信過程不造成任何影.

SSL修改密文協議
爲了保障SSL傳輸過程的安全性,客戶端和服務器雙方應該每隔一段時間改變加密規範。所以有了SSL修改密文協議。SSL修改密文協議是3個高層的特定協議之一,也是其中最簡單的一個。在客服端和服務器完成握手協議之後,它需要向對方發送相關消息(該消息只包含一個值爲1的單字節)，通知對方隨後的數據將用剛剛協商的密碼規範算法和關聯的密鑰處理，並負責協調本方模塊按照協商的算法和密鑰工作.

應用數據協議：將應用數據直接傳遞給記錄協議

應用數據的傳輸過程爲：

 

（1）應用程序把應用數據提交給本地的SSL；
（2）發送端根據需要，使用指定的壓縮算法，壓縮應用數據；
（3）發送端使用散列算法對壓縮後的數據進行散列，得到數據的散列值；
（4）發送端把散列值和壓縮後的應用數據一起用加密算法加密；
（5）密文通過網絡傳給對方；
（6）接收方用相同的加密算法對密文解密，得到明文；
（7）接收方用相同的散列算法對明文中的應用數據散列；
（8）計算得到的散列值與明文中的散列值比較；

完整數據包格式如下：

 
我本地訪問https://www.google.com，通過抓包可以清晰看出上述過程！

 
貌似該說openvpn了，答案不是！下面還要說一個內容就是ipsec。
IPsec(縮寫 Internet Protocol Security)是保護IP協議安全通信的標準，它主要對IP協議(因此它工作在網絡層)分組進行加密和認證。
  IPSec是一個用於保證通過IP網絡進行安全（保密性、完整性、真實性）的祕密通信的開放式標準框架
  IPSec實現了網絡層的加密和認證，在網絡體系結構中提供了一種端到端的安全解決方案
  IPSec加密的數據包可以通過任何IP網絡，而不需要對中間的網絡互聯設備做任何的改變
  需要知道加密的惟一設備是端點，大大降低了實現和管理的成本
IPsec作爲一個協議族（即一系列相互關聯的協議）由以下部分組成：
    (1)保護分組流的協議；如加密分組流的封裝安全載荷（ESP）或者認證頭（AH）（AH 和 ESP 主要用於數據的封裝）
    (2)用來建立這些安全分組流的密鑰交換協議。IKE協議是唯一已經制定的密鑰交換協議。
IPSec協議主要由Internet密鑰交換協議（IKE）、認證頭（AH）及封裝安全載荷（ESP）等3個子協議組成，還涉及認證和加密算法以及安全關聯SA等內容，關係圖如下： 

 
 IKE Internet 密鑰交換是一種協商和交換安全參數和認證密鑰的體系框架,用於建立IPSEC VPN特性的安全參數協商功能由IKE來完成.
      1. 協商安全參數：   身份驗證方式  封裝方式  加密方式  完整性檢測方式…
      2. 動態產生主密鑰和會話密鑰.
      3. 進行雙方的身份驗證.(通過身份認證可以保證數據的真實性。常用的身份認證方式包括：Pre-shared key，預共享

IKE是一種混合型協議，由RFC2409定義，包含了3個不同協議的有關部分：ISAKMP、Oakley和SKEME。
    ISAKMP/Oakley/SKEME是爲IKE的協商提供服務的，它提供了實現IKE的框架、密鑰交換模式和方法、密鑰的更新方法。
ISAKMP是“Internet安全關聯和密鑰管理協議”的簡稱，ISAKMP對驗證和密鑰交換提出了結構框架，但沒有具體定義，在該筐架以內，它定義了每一次交換的包結構，每次需要幾個包交換，主模式6個包交換和主動（積極）模式3個包交換，它由美國國家安全處開發，在配置IPSEC VPN的時候，只能設置它，後兩個協議不能被設置。ISAKMP被設計用來獨立的進行密鑰交換，即被設計用於支持多種不同的密鑰交換。
    Oakley描述了一系列被稱爲“模式”的密鑰交換，並詳述了每一種提供的服務。
    SKEME描述了一種提供匿名，否認，和快速密鑰更新的通用密鑰交換技術。
IKE是使用部分Oakley，部分SKEME，並結合ISAKMP的一種協議，它使用ISAKMP來得到已驗證的用於生成密鑰和其它安全聯盟（如AH，ESP）中用於IETE IPsec DOI的材料。
IKE協議是Oakley和SKEME協議的一種混合，並在由ISAKMP規定的一個框架內運作。Oakley和SKEME定義了通信雙方建立一個共享的驗證密鑰所必須採取的步驟。IKE利用ISAKMP語言對
這些步驟以及其它信息交換措施進行表述。

IKE是一個使用已知的UDP端口（端口號500）的應用層協議
IKE主要完成兩個作用：安全關聯的集中化管理，減少連接時間、密鑰的生成和管理。

AH協議  驗證報頭   可以提供身份驗證和完整性的功能, 但本身不能實現數據的加密, 而且不能穿越NAT. 不常用.

認證頭（AH）協議
    AH的協議代號爲51
    基於網絡層的一個安全協議
    IPSec協議的重要組成部分
    用於爲IP數據包提供安全認證的一種安全協議
AH的功能：爲IP數據包提供強認證的一種安全機制，具有爲IP數據包提供數據完整性（通過消息認證碼產生的校驗值保證）、數據源認證（通過在數據包中包含一個將要被認證的共享祕密或密鑰來保證）、抗重放攻擊（通過使用一個經認證的序列號來實現）等功能 .

ESP協議  封裝安全協議  可以實現身份驗證 / 加密 / 完整性等一系列安全特性. 並可以穿越NAT.

封裝安全載荷（ESP）協議
    AH只能確保IP數據包的來源和完整性，不能爲IP數據包提供機密性，即IP數據包在傳輸過程是可見的
    引入能提供機密性服務的ESP
    協議代號爲50
ESP的功能：主要支持IP數據包的機密性，將需要保護的數據進行加密後再封裝到新的IP數據包中。此外，ESP還提供認證服務，ESP只認證ESP頭之後的信息，比AH認證的範圍小

 IPSec連接需要兩個步驟：
    1.建立管理鏈接  （IKE SA） 
    2.建立數據連接   （ipsec SA）
在沒有詳細說這兩個過程的時候，先解釋一下SA

安全關聯 （Security Association）一組用於保護信息安全的策略約定, 即如何利用相關的安全參數來保護數據流,（SA可看作是一個通過公共網絡到某一特定個人、某一組人或某個網絡資源的安全通道，允許構建不同類型的安全通道）.
安全關聯——爲了使通信雙方的認證算法、加密算法保持一致，相互間建立的聯繫
安全關聯SA是構成IPSec的基礎，是兩個通信實體經協商建立起來的一種協定，決定了用來保護數據報文安全的IPSec協議、轉碼方式、密鑰及密鑰的有效存在時間
IPSec方案最終會構建一個SA的數據庫SADB，用於維護IPSec協議保障數據包安全的SA記錄
在IPSec保護IP報文前，必須先建立一個安全聯盟，可以手工或動態建立，Internet密鑰交換IKE用於動態建立安全聯盟，IKE代表IPSec對SA進行協商，並對SADB進行填充 .

SA由3個參數唯一標識
    安全參數索引（SPI）
    目的IP地址
    安全協議標識符：AH或ESP安全關聯

SPI (Security Parameter Index)，由IKE自動分配,發送數據包時，會把SPI插入到IPSec頭中,接收到數據包後，根據SPI值查找SAD和SPD，從而獲知解密數據包所需的加解密算法、hash算法等。
SA是一個單向的邏輯連接，也就是說，在一次通信中，IPSec需要建立兩個SA，一個用於入站通信，另一個用於出站通信.
使用SPI可以標識路由器與不同對象之間的連接.

建立安全聯盟的方式有兩種，一種是手工方式（Manual），一種是IKE 自動協商（ISAKMP）方式。
手工方式配置比較複雜，創建安全聯盟所需的全部信息都必須手工配置，而且IPSec 的一些高級特性（例如定時更新密鑰）不能被支持，但優點是可以不依賴IKE而單獨實現IPSec功能。 該方式適用於當與之進行通信的對等體設備數量較少的情況，或是在小型靜態環境中。

IKE 自動協商方式相對比較簡單，只需要配置好IKE 協商安全策略的信息，由IKE 自動協商來創建和維護安全聯盟。該方式適用於中、大型的動態網絡環境中。
該方式建立SA 的過程分兩個階段。第一階段，協商創建一個通信信道（ISAKMP SA），並對該信道進行認證，爲雙方進一步的IKE 通信提供機密性、數據完整性以及數據源認證服務；第二階段，使用已建立的ISAKMP SA 建立IPsec SA。分兩個階段來完成這些服務有助於提高密鑰交換的速度。

第一階段，使用ISAKMP/IKE建立管理連接時分爲主模式和積極模式（只有remote vpn和Easy vpn是積極模式的,其他都是用主模式來協商的）
主模式交換提供了身份保護機制，經過三個步驟，六個消息，頭兩個消息協商策略；下兩個消息交換Diffie-Hellman的公共值和必要的輔助數據；最後的兩個消息驗證Diffie-Hellman交換。

消息1：發送方向對等體發送一條包含一組或多組策略提議,在策略提議中包括5元組(加密算法,散列算法,DH,認證方法,IKE SA壽命)
1．策略協商，在這一步中，就四個強制性參數值進行協商：
1）加密算法：選擇DES或3DES
2）hash算法：選擇MD5或SHA
3）認證方法：選擇證書認證、預置共享密鑰認證或Kerberos v5認證
4）Diffie-Hellman組的選擇
消息2：接受方查看IKE策略消息,並嘗試在本地尋找與之匹配的策略,找到後,則有一條消息去迴應。
注意!!!發起者會將它的所有策略發送給接受者,接受者則在自己的策略中尋找與之匹配的策略(對比順序從優先級號小的到大的)（默認策略實際就是個模版沒作用，如果認證只配置預共享的話，其他參數就會copy默認策略裏的）

消息1,2交換後的結果：由於通信雙方決定了一個特定的策略組後，它們以後的通信便必須根據它進行，所以這種形式的協商是兩個IKE通信實體第一步所需要做的。

消息3和消息4，這2條消息,用於交換DH的公開信息和隨機數。雖然名爲密鑰交換，但事實上交換的只是一些DH算法生成共享密鑰所需要的基本材料信息。
兩個對等體根據DH的公開信息都算出了雙方相等的密值後,兩端主機可以各自生成出完全一樣的共享"主密鑰"，保護緊接其後的認證過程。
（D-H算法    用於在不安全的環境中, 如INTERNET, 交換隻有雙方纔知道的保密密鑰, 用於保護最初的安全協商.A和B , 公開交換一些數據, 然後各自都能根據這些數據通過複雜的數學運算，計算出一個相同的密鑰, 但別的用戶卻不能.）

消息5和消息6
這2條消息用於雙方彼此驗證,這個過程是受上面協商的主密鑰加密保護的，DH交換需要得到進一步認證，如果認證不成功，通信將無法繼續下去."主密鑰"結合在第一步中確定的協商算法，對通信實體和通信信道進行認證。在這一步中，整個待認證的實體載荷，包括實體類型、端口號和協議，均由前一步生成的"主密鑰"提供機密性和完整性保證。

在野蠻模式下，總共三個信息被交換。
    第一個信息由SA、nonce和身份組成。
    第二個信息是，在驗證發起方並接受SA後，應答方發送nonce 和身份信息給發起方。
    第三個信息是，發起方驗證應答方的身份以及進行被提議的信息的交換。
在Aggressive模式下，兩個在第一次交換髮送的身份信息是沒有加密的。Aggressive 模式的優點是信息交換快速，但加密被節省了。

第二階段協商建立IPsec SA，爲數據交換提供IPSec服務。第二階段協商消息受第一階段SA保護，任何沒有第一階段SA保護的消息將被拒收。

 

快速模式交換通過三條消息建立IPsec SA：
頭兩條消息協商IPsec SA的各項參數值，並生成IPsec 使用的密鑰。包括使用哪種IPSec協議（AH或ESP）、使用哪種hash算法（D5或SHA）、是否要求加密，若是，選擇加密算法（DES或3DES）。在上述三方面達成一致後，將建立起兩個SA，分別用於入站和出站通信。第二條消息還爲響應方提供在場的證據；
第三條消息爲發起方提供在場的證據。

有IPSec機制的數據封裝與傳遞

 
 ipsec 完整的工作過程

如圖兩個公司通過路由器組成ipsec vpn，如果172.16.7.2想給你172.16.8.2通信。

1,從172.16.7.2發送出標準的數據包，源ip172.16.7.2，目的ip172.16.8.2，通過網關送到路由器A上。
2,路由器A接受到數據包，拆包分析是到主機172.16.8.2的，查路由發現應該走ipsec通道，故檢查安全策略庫（SPD），過程如下圖。
3,在主機172.16.8.2上，把上述過程反過來執行一遍。

附：
IPSec包含有兩個指定的數據庫：
（1）安全策略數據庫（SPD）：指定了決定所有輸入或者輸出的IP通信部署的策略，負責所有的IP通信流
     SPD條目：目的IP地址、源IP地址、名稱、傳輸層協議、源端口和目的端口、數據敏感級
（2）安全關聯數據庫（SAD）：包含有與當前活動的安全關聯相關的參數（序列號計數器、序列號計數器溢出、抗重放窗口、AH信息、ESP信息、SA的生存期、IPSec協議模式、路徑最大傳輸單元MTU）

安全策略庫（SPD）說明了對IP數據報提供何種保護，並以何種方式實施保護。SPD中策略項的建立和維護應通過協商；而且對於進入和外出處理都應該有自己的策略庫。對於進入或外出的每一份數據報，都可能有三種處理：丟棄、繞過或應用IPSec。SPD提供了便於用戶或系統管理員進行維護的管理接口。可允許主機中的應用程序選擇IPSec安全處理。SPD中的策略項記錄對SA(SA束)進行了規定，其字段包含了IPsec協議、模式、算法和嵌套等要求。SPD還控制密鑰管理(如ISAKMP)的數據包，即對ISAKMP數據包的處理明確說明。
安全關聯庫（SAD）維護了IPSec協議用來保障數據保安全的SA記錄。每個SA都在SAD中有一條記錄相對應。對於外出處理，應SPD中查找指向SAD中SA的指針，如SA未建立，則應激活IKE建立SA，並同SPD和SAD的記錄關聯起來。對於進入處理，SAD的記錄用目的IP地址、IPSec協議類型和SPI標識。

SAD的查找是通過一個三元組（SAID）：協議、目的地址、SPI來進行的，三元組標識了唯一的SA。通過對SAID的散列找到SA頭，然後再進行詳細匹配找到相應的SA。

SAD和SPD之間是通過SAID進行關聯的。通過查看SPD中的SAID值，可對SAD進行查找，找到該策略項所應該實施的SA。

 

 ipsec完了嗎？看像是完了！好吧那就完了吧（我一定會回來的）！
 openvpn是個很xx的vpn，正是因爲這樣，去年gfw專門對其做關懷！他們關懷他們的，我還是要了解我的，再說開源的東西，道高一尺魔高一丈！
 對於openvpn理解我遠不如http://blog.csdn.net/dog250/article/details/6990814這位大牛！

本文出自 “面對自己” 博客，請務必保留此出處http://angus717.blog.51cto.com/1593644/1167258