まず、IPSECVPNの第一段階
双方向データUDPポート500を使用しての管理接続フェーズISAKMP / IKEとして知られている第一段階は、共有メッセージIPSECに接続されています。
第一段階メインモードとアグレッシブモードの二種類。注意！のみリモートVPNとEasy VPNモードが有効になっている、他のは、のメインモードと交渉することで
、互いのIKEピア検証を聞かせてセッション鍵、DHでの鍵交換段階を決定、我々は作成しましたIKE SAの後、後続のすべての相談には、暗号化コ整合性チェックにより保護されます
フェーズ2協議プロセスの裏には、セキュリティで保護さそうという、安全なチャネルを作成するためのピア間の相1。
マスターモードステップ3次のように、データパケットの6双方向の交換があります。
1.ルームピアは管理接続をセキュリティで保護する方法を取り決める。（変換のセットを保護するために暗号化を使用しました）
2.インターDHピアは共有鍵アルゴリズムと保護接続を使用しています。
互いに3.インターピア認証。
アクティブモードの実行中：
プロテクト接続に1.交換経営戦略、DHアルゴリズムは、ピア間の公開鍵/秘密鍵のペアと認証を構築します。
2.受信したパケットは、共有暗号鍵に検証、DHアルゴリズムを行い、接続が正常に確立されるかどうかを確認します。
PS :.メインモードに事前共有鍵認証とりわけ認証方式のデフォルトに加えて。
第二段階
クイックモード
IPSEC SAがIPSEC SAを作成するために使用されるセキュリティパラメータの交渉、IPデータストリームの暗号化にAHまたはESPを使用して
要約
-----第一段階の役割のをお互いにピア間でお互いを確認し、IKE SAをネゴシエート第二段階IPSEC SAネゴシエーションプロセス保護するために、
データ・ストリームを保護するために作成した相談の役割の第二段階のを------方法IPSEC SA、IPS
二、IPSecVPN接続ネゴシエーションプロセス、パケット
IPSECネゴシエーションは二つの相、第一主モードパッケージ6、第2ステージ3つのパッケージの合計に分割されます。1-4パケットは暗号化されたトランスポートパケット、クリアテキストで送信されて5-9。
簡単にするために、我々はこれがイントラネット例であると仮定し、各ホストは、アクティブなIPSecポリシーです：
1。（ホストA上で）ユーザは、ユーザB（ホストB上）にメッセージを送信する
2。パケットが保護され、何を保護する必要があるかどうかを確認するには、ホストA IPフィルタ判定にIPSecドライバ
3。ドライバーは予告IKEセキュリティ交渉を始めた
4。ホストB上のIKEは、要求セキュリティネゴシエーション通知を受信
5。SAの最初のフェーズを確立するために2つのホストは、共有彼らの「マスターキー」注生成：以前の通信中の2台のマシンがSAの最初のフェーズを確立している場合、SAは、相談の第二段指示することができる
6。SAは、交渉の第二段階を構築する：SAは、インバウンドとアウトバウンドのSA。キーおよびSPIを含むSA。
7。アウトバウンド・データ・パケット署名SA（整合性チェック）を使用して、および/または暗号化されたホスト上のA IPSecドライバ。
8。ホストBへ、次に転送するデータ・パケットをIPレイヤ、IPレイヤを送信するパケットドライバ
。9。ホストネットワークアダプタドライバBはパケットを受信して、IPSecドライバに送信します。
10。ホストコンピュータBのIPSecドライバは、インバウンドSAは、署名の完全性を確認し、および/またはデータパケットを復号化する使用します。
11。ドライバは、パケットがアプリケーションパケット受信ホストBを提出する上位層のTCP / IPドライバは、TCP / IPドライバを提出し、復号化
上記は、ルックスは非常に複雑なものの、完全なワークフローのIPSecですが、すべての操作は、ユーザに対して完全に透過的です。彼女は、ファイアウォール、セキュリティルーター、またはプロキシサーバーに遭遇した場合はパケットを転送するための唯一の責任を仲介ルータまたはリピータは、IPSecとIKEトラフィックが拒否されていないことを確認するためにIP転送機能を持つためにそれらを必要とします。
これは、ここで注意しなければならないのIPSec保護されたパケットの使用はNATデコードネットワークアドレスを通過することができないということです。IKEネゴシエーション運ばNAT IPアドレスを変更することはできませんので、すべての変更は、整合性チェックの失敗につながる対処します。
四、协商过程两个阶段包的另一种理解
第一阶段
准备工作
在前2条消息发送以前,发送者和接受者必须先计算出各自的cookie(可以防重放和DOS攻击),这些cookie用于标识每个单独的协商交换消息
cookie---RFC建议将源目IP,源目端口,本地生成的随机数,日期和时间进行散列操作.cookie成为留在IKE协商中交换信息的唯一标识, 实际上cookie是用来防止DOS攻击的，它把和其他设备建立IPSEC所需要的连接信息不是以缓存的形式保存在路由器里，而是把这些信息HASH成个 cookie值
1&2消息
消息1---发送方向对等体发送一条包含一组或多组策略提议,在策略提议中包括5元组(加密算法,散列算法,DH,认证方法,IKE SA寿命)
消息2---接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应
注意!!!发起者会将它的所有策略发送给接受者,接受者则在自己的策略中寻找与之匹配的策略(对比顺序从优先级号小的到大的)（默认策略实际就是个模版没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）
在1&2消息中报错可能出现的原因
1，peer路由不通
2，crypto iskmp key没有设置
3，一阶段的策略不匹配
3&4消息
这2条消息,用于交换DH的公开信息和随机数
两个对等体根据DH的公开信息都算出了双方相等的密植后,两个nonce连通预共享密钥生成第一个skeyID
随后便根据SKEY__ID来推算出其他几个skeyID
skeyID_d---用来协商出后续IPSEC SA加密使用的密钥的
skeyID_a---为后续的IKE消息协商以及IPSEC SA协商进行完整性检查(HMAC中的密钥)
skeyID_e---为后续的IKE消息协商以及IPSEC SA协商进行加密
5&6消息
这2条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的
为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥(此时由于ID还没到,彼此先用HASH来彼此验证对方)
HASH认证成分－－－SKEYID_a,cookieA,cookieB，preshare_key,SA paload,转换集，策略
在5&6消息中报错可能出现的原因
1，crypto iskmp key设置错了
消息6--接受者处理过程
1,用skeyID_e对消息进行加密 2,用ID(源IP)查找出与共享密钥 3,skeyID_a和preshare-key等一堆东西一起来计算HASH 4,和收到的HASH做比较
第二阶段(3条)
phase 2的目标是协商IPSEC SA,而且只有一种模式,快速模式,快速模式的协商是受IKE SA保护的
1&2消息
消息1---发送方发送一条报文,其中包含HASH,IPSEC策略提议,NONCE和可选的DH,身份ID
HASH:是用于给接受方作完整性检查的,用于再次认证对等体(必须)HASH的成分和5－6阶段一样
IPSEC策略提议:其中包括了安全协议,SPI,散列算法,隧道模式,IPSEC SA生命周期(必须)
NONCE:用于防重放攻击,还被用作密码生成的材料,仅当启用PFS时用到
ID:描述IPSEC SA是为哪些地址,协议和端口建立的
PFS(利用DH交换,可选):用了PFS后就会在第二阶段重新DH出个数据加密KEY,这个KEY和以前IKE协商出来的KEY没有任何关系,然后由这 个新KEY来加密数据，只有到这个IPSEC SA的生命周期后,会再次DH出新的KEY,这样,安全性就提高了（普通等ipec SA过期或密钥超时时，重新生成的数据加密密钥还是根据以阶段DH出来的skeyID_d衍生出来的）（PFS启用后，数据加密部分使用的密钥就没有了衍 生的过程）
DH:重新协商IPSEC SA实使用的密钥(正常情况下IPSEC阶段使用的密钥都是由skeyID_d衍生而来,密钥之间都有一定的关系,就算IPSEC SA超时,新的KEY还是和skeyID_d有一定的关系)
在1&2消息中报错可能出现的原因
1，ipsec trasport不匹配
2，感兴趣流不对称
消息2---使用相同的消息进行相应
3消息
发送方发送第三条消息,其中包含一个HASH,其作用时确认接受方的消息以及证明发送方处于Active状态(表示发送方的第一条消息不是伪造的)