云托管/专用服务器环境中的VPN，IPSec隧道与Tinc

我正在为云托管环境设计虚拟专用网络设置。鉴于我们的要求，我认为与专用服务器环境没有什么不同。我们的想法是让客户能够要求他们的用户使用可以提供辅助加密的VPN连接到特定的虚拟机或专用服务器（例如，用于提交回客户网络的打印作业）。

我们正在寻找支持主机到主机IPSec（ESP和AH）的主机，当然还有支持SSH隧道的主机，但是这些都不能提供使用VPN适配器的功能。因此，我们正在考虑至少添加以下一些内容，但是由于空间有限，我们希望对其中不超过一两个进行标准化（一个会更好）：

1. 虚拟主机或专用主机上的IPSec隧道支持
2. 彩
3. PPTP

由于我们进行备份等的服务器可能位于不同的数据中心，因此我们希望能够在此处重新使用我们的VPN方法。这似乎排除了PPTP。我目前的想法是，IPSec可能会更好，因为我们可以使用标准的VPN适配器，但是（根据客户要求）设置路由可能要困难得多，这就是为什么我们也在研究tinc。

这两个中的哪个更可取？我是否担心由于IPSec不合理，路由管理可能会引起严重的头痛？有没有解决此问题的简单方法？我还缺少其他有关Tinc的陷阱吗（即，除了需要一个单独的客户之外）？

更新以响应@Wintermute的答案：

是的，这个问题是从服务器的角度来看的。原因是这些服务器实际上是与客户端网络断开连接的服务器。是的，我们的目标市场是中小企业网络。是的，我们期望为每个客户端服务器使用公共IP，除非它们需要其他功能（然后我们可以进行交谈）。

我们所追求的解决方案是，客户定义IP隧道和这些隧道可访问的网络范围，并将它们与我们自己的管理工具（正在开发中）一起使用，这些工​​具将客户的请求与配置更改联系起来。问题在于，由于我们不太可能在vms和服务器上运行路由软件，因此路由表需要进行静态管理，以便配置错误的客户会发现VPN无法正常工作。

我们也很可能会通过网络使用ESP进行内部操作（例如备份）。整个设置相当复杂，并且有很多不同的观点，从以服务器为中心（我们的客户端vpn到托管实例）到以网络为中心（内部的东西），再到以数据库为中心（我们的工具）。因此，我不会说这个问题代表了我们的整个方法（并且在很多SE网站上都提出了问题）。

但是，这一切都没有真正影响到整个问题。虽然这可能是有用的上下文。

不确定tinc，但是IPSEC几乎是强制性的。没有严肃的企业会相信PPTP。

不确定IPSEC如何影响路由。隧道就是隧道，而不管加密。您将遇到相同的问题，例如：是否拆分隧道，让客户了解概念/哦，看起来特定客户的LAN IP与您选择的VPN池冲突，等等。

听起来您的目标是中小企业市场（单个服务器，直接登录等），以便排除更复杂的解决方案，但是无论如何，我将列出两种可能的方法

• 某种允许配置文件的VPN集中器。所有客户登录到VPN集中器，然后根据他们的配置文件/组/任何供应商术语，获得使用协议X到IP Y（即他们自己的服务器）的权限。

• Cisco ASR1000V虚拟路由器-每个客户都有一个，您可以运行直接IPSEC隧道（使用VTI，从而使路由看起来很容易），甚至可以将MPLS直接回馈给客户，因此路由器在其拓扑中只是另一个分支，然后分配您的VNIC内部有VLAN等，因此它们获得了不错的虚拟“分支”。

• 在上述的较小规模版本中，我们已使用monowall来达到此目的（例如，每个客户都获得了充当路由器/防火墙的第3层虚拟设备，他们将VPN接入该设备并仅访问其VLAN） ，但是每个路由器/防火墙都需要自己的公用IP地址。

关于：您当前的方法，您确实意识到然后每个服务器都需要一个公共IP，或者您拥有一个复杂且复杂的NAT系统，其中为每个客户的VPN路径分配了单个端口或类似端口。

我建议请专职网络人员来查看您拥有的任何设计/建议，这听起来好像是您来自服务器背景。

你是对的。除非您通过VPN集中器进行聚合，否则您似乎必须处理具有单独的IP。TBH集中器可能是最好的选择，对于所有VPN连接，您只需要一个额外的IP，但是其外部接口将需要与公共IP主机位于不同的子网/ VLAN中。我会同意，否则您将直接在每台服务器上配置IPSEC VPN，这是一场噩梦