既然IPsec有隧道模式，为什么还有L2TP+IPsec这样的组合？ Ipsec有隧道模式，可以用ESP或者AH进行隧道传输，即使需求加密，ESP也可以提供，那么有几个问题想不明白： 1、为什么还有L2TP over IPsec这样的组合？L2TP需要IPsec是因为L2TP本身明文传输，这一点可以理解，我的意思是既然IPsec可以单干，为什么L2TP over IPsec这样的组合还有存在的必要？ 2、在L2TP over IPsec的组合里，IPsec是不是应该使用ESP的传输模式？因为没必要再用隧道了。 先谢过各位答主。 1.你的这个IPsec单干的问题，在IKEV1的xauth或者IKEV2中已经解决了。 xauth有版权问题，可能用的不多（不了解具体市场占比，也许思科设备用的多？这里只是一面之词，仅供参考）。 至于为什么L2TP还存在而且应用还很多，是之前大家用的习惯了。IPsec远程登录的应用场景首要是稳定性，用户如果对性能没有硬性要求（其实IKEv2性能提升也不算巨大，但确实有提升，第一，登录时L2TP交互报文较多，第二，通信流量需要走IPsec，再走L2TP），或者没有什么政策强制要求，暂时没有替换的必要。 2.你可以看一下传输与隧道模式的报文封装区别。隧道模式可以保护源与目的IP，其实为了安全性，更推荐隧道模式。（当然也要看具体应用场景，不过我了解用传输模式很少了）。 我不在一线负责售前与部署工作，应用场景可能说的不一定完全对。可供参考。 L2TP协议，你可以认为是一种PPP OVER UDP形式的隧道，外层用的UDP，里面的载荷是PPP。PPP是一种链路层协议，这种协议最大的优势是可以支持用户名+密码方式的链路层认证。因此，如果希望接入VPN服务器的时候，可以针对不同的用户进行权限验证等需求，IPSEC是很难支持的。因此就出现了L2TP OVER IPSEC的用法。IPSEC一般用来在两个网络之间打隧道（比如公司的两个分支机构），L2TP用在出差员工接入公司的场景。 PPP主要就是用来做接入用户认证的，例如PPPOE就是PPP OVER ETH，用在用户的宽带接入场景。L2TP就是PPP OVER UDP，因此使用在用户接入VPN的场景。 ——————————————补充一点说明———————————- 1、PPP和eth都是链路层协议，我认为两者最核心的区别：PPP是为了点对点信道开发的，ETH是为了广播信道开发的。因此，PPP关心用户级别的验证、IP地址分配（PPP无需DHCP协议即可给根据用户名给对端分配IP、DNS）等，而ETH更需要关心冲突和寻址。 2、IKE本身是用来协商密钥的（协商DES、3DES这种块加密用的对称密钥），很明显如果密钥被窃取了，加密就没有安全性可言了，而IPSEC是用来对报文进行加密的，两者其实没有必然联系的。实际上IKE、IPSEC都是独立开发的协议，从协议栈的位置来看也是没有可比性的。只是IKE和IPSEC结合起来用的太普及了，IKE/IPSEC几乎就是一体的协议了。 3、IKE既然是用来协商密钥的，一定要支持身份认证的，当然了IKE的身份认证也很复杂，就不展开了。因此采用IKE的身份认证手段+IPSEC也是可以支持客户接入VPN场景的。 4、L2TP、IPSEC、IKE，这三个是完全独立的协议，每个协议都有其弱点和优点，以及不同的应用场景。在一些复杂的组网场景里面，采用不同的协议组合可以更好的实现一些场景，而无需修改已有的协议。因此出现了L2TP + IPSEC +IKE的用法。 这个问题讨论的无论是IPsec，还是L2TP+IPsec 都是远程访问模式，这是前提条件。 什么是远程访问模式？ 公司销售整天在外地出差，在客户那里需要一份数据，数据只有公司的服务器上有，服务器只接受内网的用户访问，销售可以远程访问公司服务器吗？ 可以的！销售可以依赖一款IPsec VPN 软件来连接公司的VPN服务器，进而访问公司内部任何服务器。无论销售身在何处，都可以访问公司内网的服务器资源，仿佛置身于公司内网一样。由于销售是在遥远地方访问公司内网，故美其名曰：远程访问！ 问题来了，内网服务器只接受内网用户访问自己，用什么条件判断是内网用户？ 使用IP地址啊，通常公司给内网用户分配10.0.0.0/8的IP地址，如果IPsec VPN用户远程可以访问，第一个条件就是获得公司内网的IP。用户在获得IP时，需要先验证用户的身份，这是标准流程。 在公司内网做这一切非常简单，先用802.1x验证用户，域控制器验证成功之后，用户就可以通过DHCP动态获得IP地址，然后用户就可以上网了。 对于远程用户，如何先验证用户身份，再给用户分配内网的IP？ 想必很多同学已经想到了这个协议，它就是PPP协议，可以完成这两个功能。 下一个问题，远程用户与公司服务器之间有Internet隔离，如何将用户的PPP Request消息运输到公司服务器，然后再把服务器PPP Response消息运输给远程用户？ 这个很难吗？ 一点也不难，用户有自己公网IP，服务器同样有自己的公网IP，用户电脑既然知道服务器的公网IP了，那就使用IP协议来传输吧！ IP/PPP 可以吗？当然可以，但是考虑远程用户电脑通常位于NAT设备后，而IP协议不便于穿越NAT设备，所以一般使用这样运输组合： IP/UDP/L2TP/PPP L2TP使用 UDP 1701端口，UDP协议是穿越NAT的利器。 L2TP L2TP是 Layer 2 Tunnel Protocol的缩写，Layer 2这里指的是PPP协议，通俗地说，这个L2TP为了运输二层协议PPP而存在的！ 问题来了，L2TP本身没有加密机制，如果不加密传输，那用户的数据在互联网上就是裸奔，这肯定无法接受。 很自然就会想到IPsec，因为IPsec可以加密，IPsec使用ESP协议来加密，ESP协议位于什么地方呢？ 是 IP/ESP/UDP(1701)/L2TP/PPP 还是IP/UDP(4500)/ESP/UDP(1701)/L2TP/PPP ？ 肯定是后者！ 前者将UDP协议加密隐藏了起来，而后者将UDP明文暴露出来，可以轻松穿越NAT设备。 作为ESP运输的货物，是加密传输的，这里只是为了便于阐述协议封装，真实的封装格式则为： IP/UDP/ESP/ESP Payload 看出来了吗？ 明文的UDP/L2TP/PPP加密之后变为 ESP的货物了，即ESP Payload。 以上的讨论解决了PPP协议在远程用户与公司服务器之间来回穿梭的问题，而且安全得到保证。 接下来就是PPP协议的工作流程，关于这个作者前几天刚写过一个回答，有兴趣的读者前去阅读，这里不再阐述了。 当PPP完成了握手流程，接下来就是传输用户的IP报文了，逻辑很简单，如下所示： IP/UDP(4500)/ESP/UDP(1701)/L2TP/PPP/IP/TCP/HTTP 想必很多同学可以看懂这辆小火车(协议封装)了吧？ 如果一上来就写这辆小火车，估计很多同学都会很迷惑不解。。。 这辆小火车，真正运输时的样子是： IP/UDP/ESP/ESP Payload 啰嗦了那么多，好像还没有回答读者的问题。其实读者的问题已经回答了80%，接下来回答剩余的20%。 第一个问题：为何有了IPsec VPN(Remote Access)，还需要L2TP + IPsec ? 那是因为前者使用 xauth认证用户， 使用mode config分配用户IP，这些东西并不完全标准化。没有标准化，不同厂商之间的互联就容易出现问题。 为了克服这种兼容性问题，使用业界标准的PPP协议，兼容性问题迎刃而解。 第二个问题，是传输模式(Transport Mode) 而不是隧道模式(Tunnel Mode)，这可以通过封装格式看得出。 更多内容，请参阅同名文章：既然IPsec有隧道模式，为什么还有L2TP+IPsec这样的组合？ 华为防火墙，配置了L2TP Over IPSec，但是用UniVPN远程拨入的时候，显示警告：“隧道保活超时或协商超时”
虽然防火墙上显示连接已经建立，dis ike error，也没有报错信息，但是实际上，远端PC与内网是无法通讯的，一旦上图中的“确定”按钮，防火墙中已建立的连接，立刻就会消失了。 根据华为官方的提示，可能的原因有：1、安全策略未放行自身到L2TP报文；2、防火墙上未启用L2TP功能；3、UniVPN上配置的“隧道名称”与防火墙上的“对端隧道名称”不符；4、两端“隧道密码认证”设置不同；5、两端IPSEC安全协议配置不同；6、路由不可达。 逐一排查后，以上原因无一有用，这可如何是好？ 实在没办法了，从头捋一遍吧，认真仔细地看防火墙上的配置。 突然发现，远端拨入的PC，身处192.168.100.1/24网段，而防火墙上有条静态路由192.168.0.0/16，出接口是g/0/0/0口，下一跳是内网核心交换机！ 不论上述“超时”错误是否与此有关，这也是需要排除的问题之一。 于是，仔细看了内网，发现只有192.168.1.0/24、192.168.20.0/24、192.168.50.0/24这三个网段，于是删除了192.168.0.0/16这条静态路由，改为三条/24的路由。
其他什么都没改，远端PC拨入成功了。
正窃喜呢，发现远端PC无法ping通内网，反之亦然。 看来，高兴得太早，始终没好事。 还能怎么办？接着分析吧，无非是路由问题。 在远端PC上，tracert -d 10.10.30.1，不出所料，一跳都没跟踪到。
在内网tracert 172.16.11.109，全从拨号的宽带出去了，根本不可能成功达到，而L2TP Over IPSec是绑定在固定IP的专线上的，显然不匹配。 跑错地方，得拽回来，纠正。 于是，配置一条策略路由，置顶。 简单来说，就是去VPN网段，不做策略路由。
在核心交换机上，ping远端PC到的IP地址，通了。
在远端PC上，ping核心交换机，也通了。
至此，华为防火墙L2TP Over IPSec故障排除。 前文列表 《未来互联网技术发展编年史，从阿帕网到完全可编程网络》《以太网技术发展编年史》《网络协议 — ARP 地址解析协议》《网络协议 — IP 互联网协议》《网络协议 — TCP 传输控制协议》《网络协议 — DNS 域名系统协议》《网络协议 — HTTP 协议 1.1 和 2 版本》《网络协议 — TLS/HTTPS 详解》 目录 IPSec 安全隧道协议族封装协议Authentication Header 协议Encapsulating Security Payload 协议封装模式Transport（传输模式）Tunnel（隧道模式）安全偶联协商Security Association 协议Internet Key Exchange 协议IKE 的对称密钥交换过程IPSec NAT-TranversalNAT-T 的封装模式NAT-T 的协商过程IPSec 的 MTU 分片和加密问题IPSec Virtual Private NetworkIPSec Virtual Tunnel InterfaceGRE over IPSec VPNL2TP over IPSec VPNStrongswan 的应用实践net2net-psk 网络拓扑base configurationmoon Sitesun Site测试运维 IPSec 安全隧道协议族 IPSec（Internet Protocol Security，互联网协议安全）是一个基于 IP 网络的安全隧道协议族，包含了一系列认证、加密、隧道封装协议。包括：安全认证协议（Authentication Header，AH）安全封装协议（Encapsulating Security Payload，ESP）安全偶联协议（Security Association，SA）安全密钥交换协议（Internet Key Exchange，IKE）
这些协议共同构建了 IPSec 的安全框架：加密算法：用于加密数据，有：对称加密算法：AES、DES、3DES 等。非对称加密算法：RSA、DH（Diffie-Hellman）等。验证算法：用于校验数据完整性，有 MD5、SHA-1、SHA-2 等。封装协议：IPSec 具有 AH 和 ESP 这 2 种封装协议，它们具有不同的安全特性，如下图所示。
封装模式：IPSec 还支持 Transport（传输模式）和 Tunnel（隧道模式）这 2 种不同的封装模式。不同的封装模式和封装格式可以组合出多种安全特性，在实际应用中需要根据不同的应用场景进行选择，如下图所示。
封装协议 在实际应用中，AH 和 ESP 封装协议可以单独使用，也可以组合使用。AH 协议可以确保数据的完整性和数据源身份认证；ESP 协议可以提供更高级别的数据加密特性；AH-ESP 协议组合可以提供最完备的安全保障，但协议开销也最高。 具体选择使用哪种协议，以及如何配置和组合它们，取决于特定的安全需求和网络环境。 Authentication Header 协议 AH（Authentication Header，安全认证协议）通常与 Transport 模式一起使用，用于 E2E 的身份认证安全通信，但不能加密数据的内容，具有以下安全特性：数据认证范围：AH 对几乎整个 Original IP Packet 进行身份认证，包括 Header 和 Payload（Header 中的可变域除外）。数据加密范围：AH 不对数据进行加密。数据完整性校验：AH 使用 HASH 算法（e.g. MD5、SHA）生成 MAC（消息认证码）的方式来校验数据的完整性。 AH 的封装格式如下图所示：Next Header（下一个头）：标识被封装数据的协议类型。Payload Length（载荷长度）：标识 Original IP Payload 的长度。Reserved（保留位）：置 0。Security Parameter Index（SPI，安全参数索引）：标识安全参数。Sequence Number（序列号）：32bits 长度的单调递增的数值，此数值溢出后，需要重新建立 SA，并使用 DH 加密算法交换密钥，以此来防止重放攻击。Authentication Data（身份认证数据）：包含了对当前 IP Packet 进行身份认证所必须的数据。
Encapsulating Security Payload 协议 ESP（Encapsulating Security Payload，安全封装协议）可以在 Transport 模式和 Tunnel 模式下使用，可以提供 E2E 或网络之间的身份认证和加密安全通信。 安全特性：数据认证范围：ESP 只会对除了 Original IP Payload 进行身份认证，并没有专门对 Original IP Header 的内容进行任何保护。数据加密范围：ESP 使用加密算法（e.g. DES、3DES、AES等）对 IP Payload 进行加密。数据完整性校验：ESP 使用 HASH 算法（e.g. MD5、SHA）生成 MAC（消息认证码）的方式来校验数据的完整性。 ESP 的封装格式如下图所示：出了会添加 ESP Header 之外还会在 IP Packet 尾部添加一个 ESP Tail 和 ESP Auth data。Security Parameter Index（SPI，安全参数索引）：标识安全参数。Sequence Number（序列号）：32bits 长度的单调递增的数值，此数值溢出后，需要重新建立 SA，并使用 DH 加密算法交换密钥，以此来防止重放攻击。Payload Data（载荷数据）：Original IP Payload。Padding（填充位）：某些块加密算法需要填充至特定的长度。Pad Length（填充长度）：标识具体的填充长度。Authentication Data（身份认证数据）：包含了对当前 IP Packet 进行身份认证所必须的数据。
封装模式 无论是 Tunnel 模式还是 Transport 模式，添加的除了 Original IP Packet 之外的封装头部和尾部的总长度不能超过 58Bytes，具体长度视乎于具体的封装模型而定。 Transport（传输模式） Transport（传输模式）具有以下特性：Transport 模式提供主机级别的安全性，因为只有 IP Payload 被加密了，而 IP Header 在网络中是可见的。所以通常用于端到端通信场景，例如：两个主机之间的通信。在 Transport 模式中，Original IP Packet 的 srcIP 和 dstIP 不会更改。
Tunnel（隧道模式） Tunnel（隧道模式）具有以下特性：在 Tunnel 模式下，IPSec 会创建一个 New IP Packet，并将 Original IP Packet 作为 New IP Packet 的 Payload 进行封装。Tunnel 模式提供了网络级别的安全性，因为整个 Original IP Packet 都被加密和认证。所以可以用于网络之间的通信，例如：在两个远程网络之间建立安全通信。
安全偶联协商 Security Association 协议 一个 IPSec 通信连接需要首先在两端建立 Security Association（安全偶联），通过 SA 协议的交互流程来协商 AH 或 ESP 封装协议所需要使用到的加密协议、对称秘钥、对端 IP 地址等信息。其中，关键的对称秘钥还需要额外的通过 IKE 协议来进行互换。 一个 IPSec 连接对应一个 SA，由 3-tuple 来唯一标识，包括：SPI（Security Parameter Index，安全参数索引）目的 IP 地址安全协议号（AH 或 ESP） 其中，SPI（32bits）用于唯一标识一个 SA，它会被添加到 AH 或 ESP Header 中。
Internet Key Exchange 协议 IKE（Internet Key Exchange，安全密钥交换协议）是建立在 ISAKMP（Internet Security Association and Key Management Protocol，互联网安全联盟和密钥管理协议）之上的、专用于保证对称密钥安全交换的自动协商协议，并提供了 SA 自动建立、CA 身份认证等功能。 使用 IKE 来建立和维护 SA，可以有效简化了 IPSec 的使用和管理，并提供更好的安全性。包括：使用 IKE 自动随机生成 SPI 的取值，代替手工生成。使用 IKE 自动生成对称密钥，代替手工生成。大规模的 IPSec VPN 端到网关场景中，往往需要使用 CA 认证机制，使用 IKE 的 CA 身份认证代替手动生成。使用 IKE 提供周期性的动态建立 SA，并且每次重建 SA 都会使用 DH（Diffie-Hellman）加密算法，使得每个 SA 所使用的 Pre-Master Secret 对称密钥都是不相同的，支持向前保密（Forward Secret）特性。AH 和 ESP Header 中基于 Sequence Number 字段的防重放保护同样需要 IKE 动态建立 SA 的机制。 IKE 支持的 SA 生命周期具有 2 种定义方式：基于时间：定义一个 SA 从建立到失效的时间；基于流量：定义一个 SA 允许处理的最大流量。 在 SA 终结条件到达后、SA 失效前，IKE 会自动协商建立新的 SA：在新的 SA 开始协商而没有协商好之前，继续使用旧的 SA 保护通信；在新的 SA 协商好之后，则立即采用新的 SA 保护通信。 IKE 的对称密钥交换过程 值得注意的是，IKE 不是简单的在网络上传输对称密钥（会遭受中间人攻击），而是通过一系列数据的交换，最终计算出双方共享的对称密钥，类似 TLS 协议。 IKE 使用了 2 个阶段为 IPSec 通信连接进行密钥协商并建立 SA：第一阶段：通信各方彼此间建立了一个已通过身份认证和安全保护的通道，即：建立一个 ISAKMP SA。第二阶段：用在第一阶段建立的 ISAKMP SA 安全隧道为 IPSec 协商安全服务，即：为 IPSec 协商和建立一个用于安全传输 IP Packets 的 IPSec SA。 其中，第一阶段具有主模式（Main Mode）和野蛮模式（Aggressive Mode）这 2 种 IKE 交换方法。主模式的 IKE 协商过程中包含了 3 对消息：第一对叫 SA 交换，是协商确认有关安全策略的过程；第二对消息叫密钥交换，交换 Diffie-Hellman 公共值和辅助数据（如：随机数），密钥材料在这个阶段产生；最后一对消息是 ID 信息和认证数据交换，进行身份认证和对整个第一阶段交换内容的认证。野蛮模式交换的主要区别在于：野蛮模式不提供身份保护，只交换 3 条消息。 所以，在对身份保护要求不高的场合，使用交换报文较少的野蛮模式可以提高协商的速度。而在对身份保护要求较高的场合，则应该使用主模式。
IPSec NAT-Tranversal 由于 IPSec 的安全加密特性，所以从技术实现上会与 NAT 存在冲突。如下图所示总结了这种冲突的情况：Transport-AH、Tunnel-AH 和 Transport-ESP 都不支持 NAPT。Tunnel-ESP 只支持一对一的 NAT，但不支持 PAT。
具体而言，Transport 模式的冲突原因如下：Transport-AH 的 Authenticate（数据身份认证）范围为整个 IP Packet，而 NAT 会修改 IP Header 的 Address，所以就会导致接收方 Authenticate 失败。同样，PAT 会修改 TCP Header 的 Port，也会导致 Authenticate 失败。Transport-ESP 的 Authenticate 范围为 ESP Header 和 ESP Tail 之间。因为 ESP 不校验 IP Header 所以 NAT 行为并不会导致接收方的 Authenticate 失败，但由于 NAT 修改了 IP Header 中的 Address，理论上后面的 TCP checksum 也会随之修改，而 TCP checksum 已经属于 ESP 校验范围之内了，NAT 设备无法进行修改，所以接收端在 TCP 层接收时会导致 checksum 校验失败。
Tunnel 模式的冲突原因如下：Tunnel-AH 的 Authenticate 范围会包含外层的 New IP Header，因此 NAT 同样会造成接收方 Authenticate 失败。Tunnel-ESP 经过 NAT 后，内层的 Original IP Header 并不会被改变，所以 TCP checksum 也不会改变，接收方也就不会再出现 checksum 失败了。但也存在着缺点：它只能支持一对一的 NAT，即：NAT 后面只有一台内网主机。如果考虑 PAT 来补充的话，又回因为 TCP Header 已经被加密而无法实现。
NAT-T 的封装模式 IPSec NAT-Tranversal 用于解决上述提到的 IPSec 和 NAT 冲突问题。而解决方案就是使用 ESP-UDP-Encapsulate 封装模式，即：在 ESP Header 前加上一个 New UDP Header，srcPort 和 dstPort 均是 4500，使得 NAT 设备按照处理一个普通的 UDP 数据报的方式对它进行处理。这个方法同时适用于 Transport-ESP 和 Tunnel-ESP 模型，以及同时支持 PAT 和 NAT。UDP-Encapsulated-Transport 模式
UDP-Encapsulated-Tunnel 模式
应用了 IPSec NAT-T 后，NAT 设备后有多台内网主机，它们都可以通过 NAT 之后并与 Server 建立 IPSec 连接了。
NAT-T 的协商过程 
IPSec 连接两端需要在 IKE 完成协商后才能使用 NAT-T。 阶段一：探测出双方都支持 NAT-T。探测出双方报文传输路径上存在 NAT 设备。前 4 个 Msg 都是使用 Sport=Dport=500 进行通信。但当探测到 NAT 设备后，作为 Initiator 再发出第 5 个 Msg 就会将端口切换到 Sport=Dport=4500，Responder 收到该消息后，如果解密成功，后续也会使用新的 4500 端口。注意，RFC3948 规定了 New UDP Header 中的端口要使用和 IKE 协商时相同的端口号，这个端口号在 RFC3947 中规定为 4500。 阶段二：双方协商 NAT-T 的封装模式，UDP-Encapsulated-Tunnel 还是 UDP-Encapsulated-Transport。其中，UDP-Encapsulated-Transport 模式还会向对方发送自己的原始 IP 地址，让对方可以据此修正后续 TCP 报文的 checksum。要知道，经过 NAT 设备之后，报文的 IP 地址发生了变化，就会导致接收端校验失败。IPsec 采用的方法是在 IKE 协商时，就将自己原始 IP 地址信息发给对端，这样 Server 在解密出 TCP 报文后，可以根据这个信息修正 checksum。 IPSec 的 MTU 分片和加密问题 由于 AH 和 ESP 封装协议会增加额外的首部和尾部，这可能会导致添加封装后 IPSec 报文超出了 L2 MTU，从而导致分片。IPSec 分片可能会引发一些问题，包括：增加网络延迟、增加网络负载、增加数据包丢失的风险等。例如：据统计 IPSec 分片可能会导致硬件加解密加速卡 50%～90% 的性能下降。这是因为 IPSec 分片首先需要进行软件重组，然后再传送给硬件卡进行解密，使得软件重组成为了限制硬件加速的瓶颈。 因此 IPSec 设备上线前往往需要仔细评估网络环境、设备能力和需求，选择合适的 IP MTU 配置策略，并进行充分的测试和验证，以确保 L2 MTU >= IP MTU + IPSec。 在大多数场景中，可以采用常规的 IP MTU 配置措施来避免 IPSec 分片，例如：修改 IPSec 设备的 IP MTU 设置，确保内层的 Original IPv4 Packet 分片再添加上外层的 IPSec 封装后仍然不会超过 L2 MTU，继而导致 IPSec 封装报文的分片。比如说，在视频流场景中，由于无法避免的大包问题，Original IP Packet 分片是固然存在的，此时需要计算并设定更小的 IP MTU。在措施 1 的基础上，通过在网络设备中启用 PMTUD（Path MTU Discovery）技术，在 L2 传输链路上进行 MTU 探测和协商出最佳的 L2 MTU 值，并在 IPSec 设备中自动调整 IP MTU 设置。 对于措施 2 而言，不同的网络设备型号会具有相应的功能特性，以 Cisco Router 作为 IPSec Gateway 时对 Tunnel-ESP（52B 开销）的处理特性为例，支持使用 ipsec 配置命令来修改对 IPSec 封装包的 PMTUD 处理，包括：clear、copy、set IP Header Flags DF 位。例如：假设整个路径上的 L2 MTU 为 1500Bytes，未设置 IP Header Flags DF（Don’t Fragment）位，存在 IPSec 分片。Router 收到发往 H1 的 1500B 的 Original IP Packet（IPv4 Header 20B + TCP Payload 1480B）。Original IP Packet 经过 Tunnel-ESP 封装，增加了 52B 的开销（New IP Header + ESP Header + ESP Tail）。此时的 IPSec 封装包为 1552B，超出了 L2 MTU 1500B，因此会进行分片。PSec 封装包被分为 2 片，分别为 1500B 和 72B（添加了额外的 New IPv4 Header 20B）。IPSec Tunnel 对端的 Router 接收到 2 个分片后，剥离附加的 New IPv4 Header，并重组为 IPSec 封装包，然后解密和解封装。最终，Router 将 1500B 的 Original IP Packet 交给 H2。假设整个路径上的 L2 MTU 为 1500Bytes，设置了 IP Header Flags DF（Don’t Fragment）位，避免 IPSec 分片。如下图所示。Router 收到 1500B 的 Original IP Packet 就将其丢弃，因为添加 IPSec 封装后会大于 PMTU（1500B）。Outer 向 H1 发送一条 ICMP 消息，并通知该 H1 下一跳 MTU 为 1442（1500 – 58 = 1442）。H1 会在其路由表中以 H2 主机路由的形式记录该信息。H1 将 H2 的 PMTU 降低到 1442B，因此 H1 在将数据重新发送到 H2 时发送更小的 Original IP Packet，然后添加 52B 的开销，由此产生 1496B 的 IPSec 封装包。由于 IPSec 封装包的 New IP Header 中设置了 DF 位，因此，采用 1400B L2 MTU 的中间路由器将丢弃此数据包。丢弃数据包的中间路由器向 IPSec 的发送端（第一个 Router）发送一条 ICMP 消息，告知其下一跳 L2 MTU 为 1400B，这个值记录在 IPSec Gateway SA 的 PMTU 中。H1 下次重新传输 1442B 的 Original IP Packet 时，Router 依旧会丢弃该数据包，因为最新的 PMTU 实际上更小。所以 Router 继续向 H1 发送一条 ICMP 消息，通知它下一跳 MTU 现在为 1342（1400 – 58 = 1342），然后 H1 再次记录此信息。当 H1 再次重新传输数据时，它使用 1342B MTU。此时，IPSec 封装包就不再需要分片了。
IPSec Virtual Private Network Virtual Private Network 是 IPSec 的主要应用场景，具体的还可以分为以下细分场景：Site-to-Site（站点到站点）：S2S 通常是 2 个 IPSec VPN Gateway 之间的互联。应用在企业的多个分支机构互联场景中，这些站点之间的多台主机的数据通过 Gateway 建立的 IPSec 连接进行安全传输。End-to-End（端到端）：E2E 通常是 2 个 IPSec VPN Client 之间的互联。应用在主机互联场景中，这些主机之间的数据通过 IPSec 连接进行安全传输。End-to-Site（端到网关）：E2S 通常是 IPSec VPN Client 和 Gateway 之间的互联。应用在两个不同网络中的主机之间的数据通过 Gateway 建立的 IPSec 连接进行安全传输。通常会采用 L2TP over IPSec 方案进行部署，即：在 L2TP VPN 基础上采用 IPSec 来提供更好的安全保护。
IPSec Virtual Tunnel Interface IPSec VTI（Virtual Tunnel Interface，虚拟隧道接口）是网络操作系统或服务器操作系统中的一种虚拟网络接口设备。 IPSec VTI 提供了一种将 IPSec VPN 配置为某个特定的网络接口上的能力，以便结合操作系统的 Routing 功能，实现将特定 Subnet 得网络流量通过特定的 VTI 发送到对应的 IPSec VPN 中。Tunnel 模式：IPSec VTI 将整个 Original IP Packet 封装在另一个 New IP Packet 中，此时 New IP Packet 的 srcIP 和 dstIP 会被更改为 Tunnel 两端的 IP 地址，然后进行加密。Transport 模式：IPSec VTI 仅对 Original IP Payload 进行加密和封装，而不会修改 IP Header，所以 Original IP Packet 的 srcIP 和 dstIP 不会被更改，IPSec VTI 仅用于加密。 使用 IPSec VTI 来建立 IPSec 安全连接具有以下优点：简化配置：通过 Routes 来确定对哪些 IP Packets 需要进行 IPSec 保护。与通过 ACL 指定 IP Flow 范围的方式相比，这种方式简化了用户在部署 IPSec 安全策略时配置上的复杂性，使得 IPSec 的配置不会受到网络规划的影响，增强了网络规划的可扩展性，降低了网络维护成本。减少开销：在保护远程接入用户流量的组网应用中，在 IPSec VTI 处进行报文封装，与 GRE over IPSec 或者 L2TP over IPSec 隧道封装方式相比，无需额外为入隧道流量加封装 GRE Header 或者 L2TP Header，减少了报文封装的层次，节省了带宽。业务应用更灵活：IPsec VTI 在实施过程中明确地区分出 “加密前” 和 “加密后” 两个阶段，用户可以根据不同的组网需求灵活选择其它业务（例如：NAT、ACL、QoS）实施的阶段。例如：如果用户希望对 IPSec 封装加密前的 IP Packets 应用 NAT、ACL、QoS，则可以在 IPSec VTI（Logical Interface）上应用策略；如果希望对 IPSec 封装后的 IP Packets 应用 NAT、ACL、QoS，则可以在 Physical Interface 上应用策略。 IPSec VTI 的工作原理 下面以更复杂的 Tunnel 模式为例。IPSec VTI 对 Original IP Packets 的封装/解封装发生在 VTI 上，并将报文的 IPSec 处理过程区分为两个阶段：“加密前” 和 “加密后”。用户流量到达实施 IPSec 配置的设备后，需要 IPSec 处理的报文会被转发到 IPSec VTI 上进行加封装/解封装。 发包封装流程：Router 将从入接口接收到的 IP 明文送到转发模块进行处理；转发模块依据路由查询结果，将 IP 明文发送到 IPSec VTI 进行加封装，Original IP Packet 被封装在一个 New IP Packet 中，New IP Packet 的 srcIP 和 dstIP 分别为 Tunnel 的 srcIP 和 dstIP。IPSec VTI 完成对 IP 明文的加封装处理后，将 IP 密文送到转发模块进行处理；转发模块进行第二次路由查询后，将 IP 密文通过隧道接口的实际物理接口转发出去。
收包解封装流程：Router 将从入接口接收到的 IP 密文送到转发模块进行处理；转发模块识别到此 IP 密文的目的地为本设备的隧道接口地址且 IP 协议号为 AH 或 ESP 时，会将 IP 密文送到相应的 IPSec VTI 进行解封装：将 IP 密文的 New IP Header 去掉，对 Original IP Packet 进行解密处理。IPSec VTI 完成对 IP 密文的解封装处理之后，将 IP 明文重新送回转发模块处理；转发模块进行第二次路由查询后，将明文的 Original IP Packet 从隧道的实际物理接口转发出去。
Linux iptables 与 VTI 的结合 最初往 Linux Kernel 增加 VTI 功能的作者提到：Virtual tunnel interface is a way to represent policy based IPsec tunnels as virtual interfaces in linux. This is similar to Cisco’s VTI (virtual tunnel interface) and Juniper’s representaion of secure tunnel (st.xx). The advantage of representing an IPsec tunnel as an interface is that it is possible to plug Ipsec tunnels into the routing protocol infrastructure of a router. Therefore it becomes possible to influence the packet path by toggling the link state of the tunnel or based on routing metrics. 这表明了 VTI 在 Linux Kernel 中也是一种虚拟网络设备，主要作用是将经过这个设备的 IP 流量打上标签，IPSec 的策略再根据这个标签和相关信息来判断流量该怎么转发。 在 Linux 中，经常使用 iptables 来为各类网络应用打标签，例如：通过 iptables 打标签给 tc 来控制流量，通过 iptables 打标签来给 iproute 来控制路由等做法。所以，通常也可以通过 iptables 给 IP 网络流量打上标签，继而实现让其数据包被 IPSec 转发的效果的。 GRE over IPSec VPN 由于 IPSec 只能加密并传输单播流量，而无法加密和传输组播数据，例如：语音、视频、动态路由协议，所以需要通过 GRE over IPSec 来弥补了这一缺陷。 首先通过 GRE（Generic Routing Encapsulation，通用路由封装）对报文进行封装，然后再由 IPSec 对封装后的报文进行加密和传输，从而保证了组播业务的安全。协议栈结构如下：
L2TP over IPSec VPN 由于 IPSec 只能加密并传输 IP 三层流量，而无法加密和传输 L2 二层流程，所以需要通过 L2TP over IPSec 来弥补这一缺陷。其封装格式如下图所示，在安全的 IPSec Tunnel 之间传输 PPP 数据帧。
Strongswan 的应用实践 Strongswan 是一个 IPSec 协议的开源实现，意为：StrongS/WAN（强安全的广域网），常用于 Linux 中。
Strongswan 具有以下特性：使用了 Linux Kernel 的 IPSec 实现，包括：AH、ESP 封装协议，VTI 等。支持 IKEv2 版本。在 IKE 阶段，Strongswan 使用了 OpenSSL 和其他安全传输层库。同时支持 x.509 证书身份认证，和基于 Pre-Shared-Key（预共享密钥）的身份认证。能被使用在 End-to-Site（端到网关）和 Site-to-Site（网关到网关）场景中。如下所示： 在 Strongswan 的官网中还可以找到大量的 TestScenarios，下面选择其中的 net2net-psk 来进行实践。 net2net-psk 网络拓扑 
Client：Alice、BobGateway：moon、sun 可见，这是一个 Site-to-Site Case 的场景。Strongswan 被安装在两个 GW 上，IPSec 采用了 Pre-Shared-Key（预共享密钥）的认证方式。实际的 IP 组网：
base configuration 安装软件 开启路由转发 修改 hosts： 关闭 SELinux： 启动 Strongswan： moon Site ipsec.conf：是 Strongswan 的主配置文件。（官网文档：https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection） NOTE：PFS 完美向前保密，用于 rekey 时。意思是：如果现在的密钥互换过程如果被攻破了，会不会对已经互换过的密钥产生影响。以前一般设置成 no 来适用于 IOS 这种客户端会以积极模式发出非加密的 rekey 请求的情况。现在这个选项完全没作用了。第一阶段永远是完美向前保密的，第二阶段（ESP）如果指定了 DH Group 那么也是完美向前保密的，但是默认加密方法就已经指定了 DH Group。所以该选项永远为 yes。ipsec.secrets：使用 PSK 方式。 NOTE：Strongswan 支持 x.509、PSK、xAUTH、IKEv2 User 等多种安全认证方式，如： strongswan.conf： charon.conf： charon-logging.conf： sun Site ipsec.conf： ipsec.secrets： strongswan.conf：同上。charon.conf：同上。charon-logging.conf：同上。 测试 clientA、clientB 可以 ping 通，表示配置 strongswan IPSec 成功。 运维 重启 Stroageswan 查看 SA 状态 查看启动日志 启动 net-net SA 连接 查看 SA 建立日志 查看 Subnet 转发的 iptables 规则。这是由 Strongswan 自动生成的 iptables 规则，完成了 IPSec VPN GW 到 Subnet IP 的转发。就不需要手动添加 route 规则了。同时，也可以查看到 mark（e.g. reqid 2）的匹配情况。tcpdump 是看不到 mark 值的，因为 mark 值在内核维护，不体现在包的内容上面。 查看 IPSec 的策略，包括其 mark（e.g. reqid 2）值等 
常用配置说明 ipsec.conf： - END – 关于 “云物互联” ： 欢迎 “云物互联” ，我们专注于云计算、云原生、SDN/NFV、边缘计算及 5G 网络技术的发展及应用。热爱开源，拥抱开源！ 技术即沟通 化云为雨，落地成林
2024最新激活全家桶教程，稳定运行到2099年，请移步至置顶文章：https://sigusoft.com/99576.html
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。 文章由激活谷谷主-小谷整理,转载请注明出处：https://sigusoft.com/77490.html
