数据包结构分析

最新推荐文章于 2024-09-04 11:09:38 发布

happylzs2008

最新推荐文章于 2024-09-04 11:09:38 发布

阅读量2.7k

点赞数 1

分类专栏： TcpDump&&Wireshark

原文链接：https://blog.csdn.net/hanbo622/article/details/39694149

版权

TcpDump&&Wireshark 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

https://blog.csdn.net/cjf1002361126/article/details/70232721

网络数据包分析与抓取

https://blog.csdn.net/liao__yong/article/details/68921898?locationNum=10&fps=1

网络数据包转发过程

https://blog.csdn.net/hanbo622/article/details/39694149

通过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报文。握手结束，客户与服务器可以发送应用层数据了。当客户从服务器端传送的证书中获得相关信息时，需要检查以下内容来完成对服务器的认证：时间是否在证书的合法期限内；签发证书的机关是否客户端信任的；签发证书的公钥是否符合签发者的数字签名；证书中的服务器域名是否符合服务器自己真正的域名。服务器被验证成功后，客户继续进行握手过程。

同样的，服务器从客户传送的证书中获得相关信息认证客户的身份，需要检查：用户的公钥是否符合用户的数字签名；时间是否在证书的合法期限内；签发证书的机关是否服务器信任的；用户的证书是否被列在服务器的LDAP里用户的信息中；得到验证的用户是否仍然又权限访问请求的服务器资源。

SSL报警协议是用来为对等实体传递SSL的相关警告。如果在通信过程中某一方发现任何异常,就需要给对方发送一条警示消息通告。警示消息有两种：
Fatal错误,如传递数据过程中发现错误的MAC,双方就需要立即中断会话,同时消除自己缓冲区相应的会话记录.
Warning消息,这种情况,通信双方通常都只是记录日志,而对通信过程不造成任何影.

SSL修改密文协议
为了保障SSL传输过程的安全性,客户端和服务器双方应该每隔一段时间改变加密规范。所以有了SSL修改密文协议。SSL修改密文协议是3个高层的特定协议之一,也是其中最简单的一个。在客服端和服务器完成握手协议之后,它需要向对方发送相关消息(该消息只包含一个值为1的单字节)，通知对方随后的数据将用刚刚协商的密码规范算法和关联的密钥处理，并负责协调本方模块按照协商的算法和密钥工作.

应用数据协议：将应用数据直接传递给记录协议SSL报警协议是用来为对等实体传递SSL的相关警告。如果在通信过程中某一方发现任何异常,就需要给对方发送一条警示消息通告。警示消息有两种：
Fatal错误,如传递数据过程中发现错误的MAC,双方就需要立即中断会话,同时消除自己缓冲区相应的会话记录.
Warning消息,这种情况,通信双方通常都只是记录日志,而对通信过程不造成任何影.

应用数据协议：将应用数据直接传递给记录协议

应用数据的传输过程为：

（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