IPSec 隧道模式 vs 传输模式 vs 传输+L2TP

IPSec 隧道模式 vs 传输模式 vs 传输+L2TP

根据许多文档,主机到主机 IPSec 应使用传输模式,而隧道用于连接网关,L2TP 用于远程访问。

但是没有什么可以阻止我在网关到网关中使用传输模式,对吗?一个网关可以读取 ESP(或 AH),将其删除,然后将裸 IP 数据包路由到其网络。

我也可能在我的 PC 和数据库服务器之间使用隧道模式。将每个数据包包装在单独的 UDP 中可能有些多余,但可用。

如果我的 PC 上只有我一个用户,我可以使用裸 IPSec(不使用 L2TP)进行远程访问。我不会进行记账、通过 IPCP 进行网络配置和其他 PPP 操作,但这些并非总是必需的。

毕竟L2TP可以用来连接2个网关;)

那么,我的问题是,为什么所有这些方法都存在并且相互重复?如果几乎总是可以将其更改为隧道传输,反之亦然,为什么 IPSec 传输仍然存在?您能否举个例子,说明其中一种方法是“唯一正确的方法”?

答案1

如果几乎总是可以将 IPSec 传输更改为隧道传输,反之亦然,为什么 IPSec 传输仍然存在?

我目前还没有看到传输模式 IPSec 在一般联网设备用户中使用。我认为它从未积累足够的势头来得到普遍部署。软件和网络供应商有动力向有远程访问需求的企业客户销售隧道模式实现(以及广泛的后端),但没有向任何人推广传输模式。这些功能可能已经存在,但易用性仍然有很多不足之处。

所以它确实存在,但它仍然有意义吗?交通方式在历史上并不是很多用户都能使用的。但自由软件用户是个例外。

IPsec 机会加密的历史和实施现状

上面的链接描述了将 IPSec 广泛应用的历史努力,以及这些努力如何受阻。原因可以概括为互联网基础设施(即 DNS)的不安全性,以及相关人员对改变它相对自满。

为什么所有这些方法都存在并且相互重复?

所有这些方法的存在主要归功于对安全远程访问需求变化的独立识别和解决方案,时间大致相同。您的问题略微改进的版本可能是“为什么所有这些方法仍在使用?”

您已经回答了为什么 L2TP 仍在使用的问题:记帐和配置。(看看为什么其他协议(如 PPTP)不再使用可能会更有趣。)在许多情况下,即使您不关心记帐和配置,

在其他情况下,答案并不那么明确。以网关到网关的情况为例。您可以使用纯隧道模式 IPSec,或者使用基于 IPSec 的 GRE 隧道(事实上,我相信它们是基于传输模式 IPSec 的)。除了熟悉之外,我不知道这两种方式还有什么优势。就我个人而言,我从未在 Cisco 路由器上设置过隧道模式 IPSec。我一直使用加密 GRE。为什么?因为我对纯 GRE 的了解都适用于加密 GRE。所以对我来说很熟悉。

不要忘记应用程序级 VPN/隧道,例如 OpenVPN 或 Secure Shell。这些通常比内核或设备级实现的性能更差。但它们通常更易于使用,并且具有更容易通过代理和防火墙的优势(至少在深度内容检查出现之前)。此外,它们通常具有更少的依赖性;在旧的 Linux 服务器上编译 OpenVPN 比重新编译内核以支持 IPSec 要容易得多。

您能否举例说明其中一种方法是“唯一正确的方法”?

在网络中(与计算中的许多情况一样),您永远不会看到“唯一正确的选择”。在大多数情况下,您只能使用可行的方法。例如,所有 Android 设备都可以使用基于 L2TP 的 VPN。因此,即使您不需要配置或记帐,这也是可行的。我对 Cisco 设备上的 GRE 隧道很熟悉,因此比纯隧道模式 IPSec 更容易实现它们。而且我可以在无法升级的古老 Linux 服务器上创建 OpenVPN 或基于 SSH 的隧道(出于某种原因)。

答案2

  • IPsec 隧道与传输模式
    • 隧道模式的开销更大
    • 传输模式仅在主机之间有效,因为包装不包含额外的 IP 地址集
  • 开销是个问题吗?
    • 想象一下,主机在进行任何通信之前彼此之间建立 IPsec 关联 ** IPsec 将无处不在 ** 在隧道模式下,每个数据包中的 IP 地址将出现两次 → 浪费资源

相关内容