一个典型的 VPN 客户端是这样工作的：它连接到服务器，然后它指示操作系统给他所有要发送到给定集合中任何地址的数据包。例如，假设 VPN 客户端宣传它应该处理所有发往 10.0.0.0/8 的数据包（即所有以“10”开头的 IP 地址）。当操作系统看到一个应该去地址“uvwx”的数据包时，它检查“u”是否为“10”；如果是，那么它将数据包提供给 VPN，VPN 对其施展魔法并将其转发给服务器；否则，数据包会像操作系统在没有 VPN 客户端的情况下所做的那样“发送到 Internet”。

这个系统如何实现的细节取决于 VPN 的实现（例如，它可以声明特定的“路由”；或者它可以拦截所有带有防火墙规则的传出数据包并重定向它感兴趣的数据包；...）。

如果您有两个 VPN 客户端，并且它们的“广告地址集”不重叠，那么它们很可能会在 IP 级别很好地共存：每个客户端都会为自己的虚拟网络获取数据包，而其他数据包不受影响。但是，他们也可能会争夺“拦截资源”，这可能导致第一个 VPN 客户端完全停用。

另一方面，如果两个 VPN 都宣传重叠的地址集，那么几乎肯定会出现问题。如果幸运的话，第二个 VPN 将拒绝运行并显示显式消息。否则，其中一个客户端可能会优先，可能是间歇性的，事情会变得奇怪和混乱。一个 VPN 服务器可能会接收到另一个 VPN 应收到的数据包，从而导致严重的数据泄漏。

DNS 会有问题。应用程序和人类不想处理IP 地址，而是处理主机名。DNS 将主机名转换为 IP 地址。VPN 是一个“虚拟专用网络”，它使用对全球 Internet DNS 不可见的名称。因此，VPN 客户端不仅会拦截 IP 数据包，还会拦截名称解析系统，并将部分（如果不是全部）名称解析请求重定向到 VPN 上的专用 DNS 服务器。

您的两个 VPN 客户端将竞争该重定向。如果客户端设法仅重定向某些域的请求，事情可能会运作良好。但很有可能会发生hijinks。一个 VPN 的某些名称可能会停止转换为 IP 地址，从而导致功能减少。一个 VPN 可能会收到另一个 VPN 的名称解析，因此不仅功能被破坏（因为一个 VPN 中的 DNS 不知道如何处理来自另一个 VPN 的名称），而且一些私人数据从一个 VPN 泄漏到另一个 VPN （主机名很少非常敏感，但这仍然是泄漏）。

在最后一种情况下，接收到另一个 VPN 的私有名称的名称解析请求的 VPN 处于理想的位置，可以用伪造的 DNS 答案进行响应，并将来自另一个 VPN 的所有流量重定向到它自己。

所以不要那样做。同时运行多个 VPN 客户端会带来麻烦、难以诊断的故障和潜在的数据泄露。

为避免多个 VPN 出现问题，您应该努力使用更多“受控”形式的 VPN。例如，带有 ssh 的 SOCKS 代理。这将允许您运行一个 Web 浏览器，将其所有流量重定向到另一台主机（“VPN 服务器”），同时保持机器的其余部分（以及至关重要的其他浏览器实例）不变。例如，请参阅此答案。一些纯粹主义者说这样的代理不是VPN，但出于许多实际目的（实际上是基于 Web 的任何东西），这在功能上是等效的。另请参阅基于端口的隧道的替代方案。

我曾经一次做很多事情（十几个基于端口的隧道，还有 SOCKS 代理，一切都运行良好）。SOCKS 解决方案也适用于名称解析：来自 Web 浏览器的名称解析请求将通过隧道，在另一端（即在 VPN 中）进行解析，而无需触及本地 DNS 配置。基于端口的隧道需要静态本地名称声明。

例如，我使用 Cisco Any Connect 进行连接，然后使用另一个 VPN 客户端（例如 HotSpot Shield 或 proXPN）通过另一个隧道进行连接。

我假设您在一台计算机上使用两个客户端，因此您有两个并行隧道，而不是一个在另一个内部（如果您从计算机连接到 Server1，然后启动VPN2 以连接 Server1 和 Server2 ）。

在第一个（并行）场景中，每个 VPN 客户端将创建自己的虚拟接口，具有自己的地址、网络掩码、远程网关和相关路由。

通过隧道发送的任何数据都将通过该隧道而不是其他隧道加密，因此问题变成：您的计算机如何确定哪些数据通过哪个隧道发送？

这是通过客户端上的路由规则完成的。例如，您可能会在 VPN1 上收到地址 192.168.42.17/24，在 VPN2 上收到地址 192.168.77.13/24。如果您尝试与主机 .42.33 链接，您将通过 VPN1，而 VPN2 对此一无所知。

现在，192.168.42.0/24 可能只是您和服务器之间使用的专用网络，即由 Server1 分配给其所有 VPN 客户端的专用网络；Server1 服务的真实网络可能是 10.20.30.0/24，因此 Server1也会添加到 10.20.30.0/24 到 192.168.42.1 的路由；然后，当您尝试连接到 10.20.30.137 时，该连接将流经 VPN1，被加密，而 VPN2 甚至不知道这正在发生（为什么要这样做？）。

可能出现的问题：如果VPN1 和 VPN2都为同一子网广播了一条不对应相同物理主机的路由，会发生什么情况？例如，您有两个配置完全相同的办公室，ServerAtOffice1 的地址为 10.20.30.137，而 ServerAtOffice2 的地址为 10.20.30.195。由于这两个网络从不相互交谈，因此根本不会发生冲突。

直到你启动 VPN1，它告诉 10.20.30.0 通过 VPN1，然后也启动 VPN2，它告诉你，不，10.20.30.0 通过 VPN2 而没有其他人。

在这种情况下会发生什么取决于 VPN 客户端。一个聪明的客户端会告诉你“嘿，我正要路由 10.20.30.0 但是，你知道吗？这条路由已经到了其他地方，也许我可以通知我的系统管理员，以防万一一些活泼的东西”。

或者你可能有两个愚蠢的客户端，最后一个覆盖对方的配置请求是为了获利。

或者可能会发生更奇怪的事情，连接可能会开始工作，然后在几个数据包后混乱地死掉。

最后一种可能性可能是两个客户端都希望通过自己设置默认路由 - 一条用于您不知道的地址。

然后，当连接到 Server1 时，您的所有 Internet 导航都可以通过 Server1 加密。然后你也启动了 VPN2，“默认”导航通过 VPN2 路由。现在，您所有关于客户 #1 的 Google 查询都通过客户 #2 的网络、防火墙、数据包分析器等明确路由；这可能会带来无穷无尽的麻烦，这取决于您的角色和两个客户的友好条款。

调整

我怎么能做其他版本，而不是两个客户端并行？如果我在运行 PPTP VPN 服务器的路由器 ALPHA 上运行 DD-WRT，

您从客户端连接到的人CHARLIE，

我可以让它连接到 VPN 服务器 BRAVO 吗？这是链接隧道吗？无论如何，最终服务器会看到我的流量来自中间的路由器，对吗？——拉斯洛

我们在这里可以有两种情况（我已经为你的机器添加了名称）。

在第一个场景中，ALPHA 本身也是服务器 BRAVO 的客户端 DELTA。在这种情况下，来自 CHARLIE 的数据包通常被服务器 ALPHA伪装，因此 BRAVO 服务的任何客户端都将数据包视为来自 DELTA。如果 BRAVO 的客户与 ALPHA 的客户有相同的方案，这可能很难或不可能做到，因为在这种情况下，您可能对谁拥有地址 192.168.112.17 有歧义；是 ALPHA 的第 17 位客户还是 BRAVO 的第 17 位客户？

在第二种情况下，ALPHA 只是路由，因此您现在可以通过 ALPHA 的 VPN 使用 BRAVO。因此，您在第一个 VPN 隧道中打开第二个 VPN 隧道，并由 BRAVO分配第二个 IP 地址。您现在同时是服务器 ALPHA 的客户端 CHARLIE和（ALPHA 不知道的）服务器 BRAVO 的客户端 DELTA。

BRAVO 的客户会将您视为 DELTA，而 BRAVO 当然会知道您是 ALPHA 的客户 CHARLIE。

如果地址和它们的路由冲突（例如，与 BRAVO 的连接依赖于默认路由，但 BRAVO 本身在 connect 上安装自己的默认路由，用 ALPHA 替换），您可能会再次遇到麻烦。

此外（即使现在这已变得无关紧要），在第二种情况下，ALPHA 上的负载较低，而您的 CPU 上的负载相应地较高（所有发送到 BRAVO 网络的数据包都由 BRAVO-Driver 加密，然后传递给 ALPHA-Driver并重新加密，最后被传递给 ADSL-Driver 并在途中发送）。

两种情况，两种可能：

您可以启动从笔记本电脑 到cisco的客户端连接，而不是从cisco 到最终目标的第二个连接：

<laptop> ---- <cisco> ... <cisco> ---- <final>

在这种情况下，数据将在cisco主机上以明文形式传输。

或者，您可以启动从笔记本电脑 到cisco的客户端连接，而不是从笔记本电脑 到最终目标的第二次连接：

<laptop> ---- <cisco> .... <final>
<laptop> ----------------- <final>

在这种情况下（虽然两个加密隧道都是从同一主机连续启动的：笔记本电脑），它将是 atunnel within a tunnel并且cisco不会看到未加密的数据。

注：在这，

----  mean encrypted connection and
....  mean unencrypted (local or network) connection

从理论上讲，它将是隧道中的隧道。第一个隧道位于您的计算机和第一个 VPN 端点之间。第二个隧道通过第一个隧道到达第一个 VPN 端点，在此它退出第一个隧道，然后到达第二个 VPN 端点。

我说理论上是因为我认为这取决于 VPN 客户端如何设置连接和路由表。第二个 VPN 客户端可以设置路由表和度量，即使您在上面的隧道理论设置中有隧道，数据也会发送到第一个隧道，而第二个隧道根本不会使用。