也许你可以帮我解决一个小问题。
您会推荐 IPSec 或 TLS 用于服务器到服务器的连接吗？在我的期末论文中，我需要两三个论据来推理一个决定，但遗憾的是没有找到排除标准。在我的论文中对 IPSec 和 TLS 的反映只是一个小方面，因此，选择 TLS 或 IPSec 的一两个主要原因就足够了。您认为 IPSec 中可能的压缩可能是这些主要原因之一吗？
更完整的场景解释：
用户想要登录门户以使用服务。门户后端由门户本身、注册机构、用户管理、访问控制机构等组成。我应该选择 TLS 还是 IPSec 来保护这些后端连接？交付的服务不必定位在后端，但它是可靠的，并且只与门户连接。这是我要保护的连接的列表：
服务（可能是外部的）----门户
注册权限----用户管理
门户----用户管理
对于用户服务器连接，我已经做出了决定，但我用于此决定的原因不适用于服务器到服务器连接。
提前非常感谢！
场景图片：
（红色 = 有问题的连接）
（事实上，这个模型要大得多，因为我还处理了其他机制，如身份验证、存储机制、存储访问、访问控制、软件架构，包括可能的技术等。因此，保护连接只是一个部分方面)
IPsec有两种主要的使用模式：AH和ESP。AH仅用于身份验证，所以我想您是在谈论两台服务器之间的 ESP 隧道。所有 IP 数据包都经过加密和身份验证，包括一些标头详细信息，例如源端口和目标端口。有几种加密和 MAC 算法可以与 IPsec 一起使用；AES（CBC 模式，128 位密钥）和 HMAC/SHA-1（截断为 96 位）很好，并且是必须实现的，因此任何符合 IPsec 的实现都应该支持它们。
对于这个“隧道”部分，IPsec 正确地做事，TLS 也是如此（假设 TLS 1.1 或 1.2，用于在 CBC 模式下使用块密码进行 IV 选择）。事实上，IPsec 可以被认为比 TLS“更正确”，因为它使用 encrypt-then-MAC 而不是 MAC-then-encrypt（请参阅this）；但是，正确实施的 TLS 1.1 或 1.2 也可以。实际差异将出现在其他级别：
要加密和解密数据，您的两台服务器必须首先就共享密钥达成一致。这就是TLS 中握手的意义所在；IPsec 中的等价物是IKE。您可能希望依赖X.509 证书；或者可能在两个服务器中手动配置的“共享密钥”上。TLS 和 IPsec 两者都支持，但是任何一个的特定实现都可能使一个选项比另一个选项更容易或更复杂。
IPsec 在操作系统级别起作用；应用软件不需要知道IPsec 的存在。这在某些情况下很好，在其他情况下则不是很好。一方面，它允许使用 IPsec “保护”一些遗留应用程序，即使在应用程序开发过程中没有设想到这一点；并且可以在不受应用程序开发人员所想的约束的情况下完成安全管理（例如，如果使用 X.509 证书，您可以强制执行吊销检查，而支持 TLS 的应用程序可能使用不支持 CRL 的库） . 另一方面，使用 IPsec，应用程序不能做任何特定于应用程序的安全操作：例如，服务器可能不会根据其他服务器与其通信的情况来改变其安全管理。
尽管 TLS 通常用于应用程序，但也可以将其用作两台服务器之间的操作系统级VPN的构建块。这基本上意味着像使用 IPsec 一样使用 TLS。
IPsec 是操作系统级别的，它的操作意味着摆弄操作系统级别的网络配置，而 TLS 通常可以保持在应用程序级别。在大型组织中，网络人员和应用程序人员往往生活在不同的世界中（遗憾的是，他们经常相互交战）。出于组织原因，将所有内容保留在应用程序层可能会使部署和管理更容易。
总结：视情况而定。如果您想将 IPsec 应用于不合作的应用程序（例如，本机不支持对其与其他服务器的连接进行任何保护的应用程序），请使用 IPsec。如果您想抽象出操作系统级别的配置，请使用 TLS。如果您仍想在操作系统级别使用 TLS，请使用支持 TLS 的 VPN。
您想到了哪种 TLS 实现？隧道？IPsec 和 Stunnel 提供了相当的安全性，但 Stunnel 更容易设置。IPsec 具有更陡峭的学习曲线，但提供了更多功能，包括在两侧与 SELinux 一起使用时标记网络的圣杯。