IPsec IKEv2详解：与IKEv1的区别、协商过程及故障排查
IPsec IKEv2详解：与IKEv1的区别、协商过程及故障排查
在本教程中，我们将深入探讨IPsec IKEv2的相关知识，包括IKEv1和IKEv2的区别、IKEv2的协商过程，以及如何监控和调试IKEv2隧道。通过学习这些内容，你将能够更好地理解和应用IPsec IKEv2技术。
在本课中，你将了解IPsec IKEv2。
完成本课后，你应该能够实现上图显示的目标。
通过展示对IPsec IKEv2的充分理解，你将能够解释IKEv2及其协商过程的差异和优势。
在本节中，你将了解IKEv1和IKEv2之间的区别。
虽然IKEv1仍然被广泛使用，但在决定是继续使用IKEv1还是更换它时，你必须考虑多个因素。值得注意的是，IKEv1的开发在十多年前就停止了，未经维护的代码可能会导致安全漏洞。IKEv1已移至历史状态，其一些RFC规格已过时。
IKEv1中使用的一些算法不再被积极部署或研究，这带来了你应该避免的未知安全风险。一些IKEv1功能从未达到标准状态，有些甚至没有RFC。
尽管IKEv1已弃用，但它仍然可以满足一些系统要求：
● 当作为拨号客户端的FortiGate设备需要RADIUS或LDAP身份验证时：由于FortiOS没有可扩展身份验证协议（EAP）客户端，FortiGate设备无法对RADIUS或LDAP服务器进行身份验证。在这种情况下，必须使用IKEv1。
● 当需要多个阶段的身份验证时：虽然IKEv2可以为这一要求提供解决方案，但它需要多个身份验证交换或使用基于隧道的EAP（TEAP）的EAP链。
FortiOS已经使用IKEv1超过20年，它推动了修复和优化。
IKEv1和IKEv2是不兼容的协议，可以实现相同的目标，但方式不同。
IKE版本2不与IKE版本1互操作，但它们都有足够的共同的标头格式，两个版本都可以明确地在同一UDP端口上运行。
虽然核心IKEv1功能是通过多个RFC定义的，但主要的IKEv2 RFC在单个文档中涵盖了许多相同的功能，如网络地址转换-横向（NAT-T）、模式-cfg、EAP、死对等检测（DPD）等。
过渡到IKEv2有多种原因：
● IKEv2是一个强大而可靠的协议，开发人员正在积极研究。
● IKEv2协商需要更少的消息，这意味着在建立隧道时减少了延迟。初始交换是两次往返（四条消息），这允许子SA的设置附带在该交换上。
其他新的改进如下：
● 碎片化的协商从第一条消息开始。
● DoS保护。
● IKE/IPSEC SA的重键逻辑定义更准确。
● 为简化实现和安全性分析，将保护IKE消息的密码语法替换为紧密基于ESP的密码语法。
迁移到IKEv2的其他原因有：
● 使用标准EAP作为身份验证和非对称身份验证
● 按ID匹配拨号第1阶段的选项
IKEv2为流量选择器提供了灵活性。你可以为每个流量选择器指定有效负载类型，而不是用ID有效负载超载它们。
IKEv2还支持使用叠加网络ID、SA会话恢复和快速崩溃检测的设置。
上图总结了IKEv1和IKEv2中IPsec功能的比较。
关于交换模式，在IKEv1中，野蛮模式提供了减少第1阶段交换次数的优势。相比之下，IKEv2不使用主模式或野蛮模式；然而，其相当于第1阶段的模式可能只需要两次交换。
在身份验证功能中，在IKEv1中，身份验证必须是对称的。IKEv2提供了灵活性，允许发起者和响应者在协商期间使用不同的身份验证方法。
作为IKEv2改进的一部分，NAT-T是一个内置功能。IKEv1不原生支持NAT-T。NAT-T功能后来被包括在内，以使IKEv1能够通过NAT设备工作。
IKEv2的另一个改进是流量选择器的灵活性，它允许对IPsec隧道保护的流量进行更精细的控制。IKEv2还支持在建立子SA后动态更新流量选择器。
在本节中，你将了解IKEv2交换用于协商IPsec隧道的步骤。
与IKEv1不同，IKEv2是一个可靠的协议：发起者重新发送请求，直到它收到相应的响应或认为IKE SA失败。在后一种情况下，发起人丢弃了IKE SA以及与无响应的同行协商的任何子SA。
IKEv1有一个明确划定的第1阶段交换，其中包含六个数据包，然后是三个数据包的第2阶段交换。IKEv2交换是可变的。充其量，它只能交换四个数据包。最坏的情况是，这可能会增加到多达30个数据包，这取决于身份验证的复杂性。
初始交换发生后，任何后续流量都会触发CREATE_CHILD_SA交换，这相当于IKEv1中的第2阶段交换。
IKEv2没有野蛮模式或主模式。
IKEv2不使用第1阶段或第2阶段的概念，但FortiOS CLl和GUl命令和术语以IKEv1为中心，因此你在配置IKEv2设置时确实使用了这些概念和术语。
IKEv2 SA的设置配置在第1阶段进行。子SA的设置配置在第2阶段进行。
在IKEv2谈判期间，有四个交换。初始交换是：IKE_SA_INIT和IKE_AUTH。
IKE_SA_INIT交换：
● 协商安全配置，保护IKE流量。
● 启用DoS保护（cookie机制）。
IKE_Auth交换：
● 执行两个IKE端点的相互身份验证。
● 配置IP/掩码、DNS等设置。
● 设置子SA的搭便车。为IPsec SA进行IP流和安全设置的谈判。
Create_Child_SA交换：
● 创建一个新的子SA或重新键换现有的子SA。
● 更新IKE SA。
信息交换：
● 在IKE端点之间传输控制消息。
使用IKE的通信总是从IKE_SA_INIT和IKE_AUTH交换开始（在IKEv1中称为第1阶段）。SA_INIT是IKEv2初始交换的第一次往返。SA_INIT交换通常需要一次往返。
如果响应者请求另一个密钥交换（INVALID_KE_PAYLOAD通知），或者如果DoS保护（cookie通知）启动，交换将扩展到两次往返。
如果密钥交换重新协商和DoS保护都完成，交换将增加到三次往返。
IKE_AUTH（身份验证）在SA_INIT之后进行，是初始交换的最后阶段。它受加密算法和SA_INIT密钥的保护。
双方交换他们的身份——ID发起者（IDi）或ID响应者（IDr）——并提供他们声称的身份（AUTH）的证明。
当不使用EAP时，IKE_AUTH由单个请求和响应交换组成。使用EAP时，IKE_AUTH由多个请求和响应交换组成。交换的数量取决于正在使用的EAP方法。
默认情况下，在IKE_AUTH过程中与IKEv2安全联盟协商一个IPsec (piggyback child)安全联盟。如果需要额外的IPsec sa(例如配置了多个FortiOS阶段2)，则在后续的CREATE_CHILD_SA交换过程中协商。
根据IKEv2的设计，在IKE_AUTH交换过程中不需要交换Diffie-Hellman公钥。因此，fortify和对等体之间的任何phase 2 Diffie-Hellman组配置不匹配，只会在IKE_AUTH创建的子SA第一次更新密钥(CREATE_CHILD_SA exchange)时发生。
此交换由单个请求和响应对组成，在IKEv1中被称为第2阶段交换。初始交换完成后，它可以由IKE_SA的两端发起。初始交换之后的所有消息都使用IKE交换前两条消息中协商的加密算法和密钥进行加密保护。所有后续消息都包含一个加密的有效负载，即使它们在文本中被称为“空”。任一端点都可以启动CREATE_CHILD_SA交换，因此在此交换中，“发起者”一词指的是启动此交换的端点。
在IKE_SA操作过程中的不同点，同行可能需要相互传达有关错误或某些事件通知的控制消息。为了实现这一目标，IKE定义了信息交换。信息交换只能在初始交换后进行，并受到协商密钥的加密保护。
在本节中，你将学习用于监控IKEv2隧道的命令，以及用于调试和排除IKEv2故障的命令。
监视、调试和排除IKEv2故障的命令与IKEv1相同。
diagnose vpn ike gateway list命令可以提供隧道的详细信息。diagnose vpn ike gateway clear命令用来关闭阶段1。在进行故障诊断时，可以使用此命令强制进行隧道协商，但请谨慎使用。
diagnose vpn tunnel list命令用来显示当前所有激活隧道的IPsec SA信息。
为了调试IPsec IKEv2的连接，可以像IKEv1一样使用命令diagnose debug application ike，并使用命令diagnose vpn ike log filter应用过滤器，以收集指定隧道的调试输出。
启用调试命令diagnose debug application ike并启动IPsec协商后，可以分析IKEv2协商过程。
在最初的谈判中，你可以看到SA INIT交换。上图显示SA INIT已发送，发起者收到了SA_INIT响应。
成功进行SA INIT交换后，将进行IKE_AUTH交换。调试输出显示收到的主题和此响应。
上图显示了发起人发送的AUTH交换及其收到的回复。
成功交换IKE_SA_INIT和IKE_AUTH后，发生CHILD_SA交换。
在此交换中，同行协商CHILD_SA和流量选择器——流量选择器响应器（TSr）和流量选择器发起器（TSi）。
上图展示了你在本课中涵盖的目标。
通过掌握本课中涵盖的目标，你了解了对IKEv2的改进、其协商过程以及如何使用IKEv2协议调试IPsec隧道。
本文原文来自CSDN