☰

我的 VPN 到底应该有多慢？

tag-icon • tag-icon vpn ipsec draytek
我的 VPN 到底应该有多慢？

我在具有 2 个 ADSL 连接（下行 8Mb、上行 512Kb）的远程办公室与具有 10Mb EFM 连接（上行和下行均为 10Mb）的主办公室之间设置了 VPN。

VPN 是一种 IPSec 连接，使用 DrayTek 2930 路由器连接 ADSL，使用 DrayTek 3200 路由器连接 EFM 端。但是，我无法通过此连接（使用 iperf 测试）从主办公室获得超过 600Kb 左右的速度（流量几乎总是从主办公室流向远程办公室）

虽然我意识到这会产生开销，并且我永远无法获得此 VPN 提供的“全部”带宽，但我认为我应该考虑一些可能有助于改进它的东西。

我尝试使用 DrayTek 的内置“VPN 中继”功能，该功能应该可以平衡连接负载，但这似乎并没有带来太大的改善。

我想我的问题是 - 这是我应该从这种设置中期望获得的性能吗？我是否必须忍受它，或者我是否应该能够通过一些 VPN 魔法从中获得更多的东西？

答案1

问题是许多带有 VPN 服务器/客户端的廉价路由器实际上无法以线速（甚至无法以全 WAN 速度）使用 VPN 功能。

我曾经管理过一家公司，总部有一台 Draytek Vigor 2950，最初连接到 2Mb 服务，后来我们将其升级到 50Mb。通常有 10-15 个远程站点使用 Draytek Vigor 2800/2820 进行连接。

当我们升级到 50Mb 时，我们发现我们仍然无法使用超过 2Mb 的 VPN 带宽的站点。我使用家用电脑作为 VPN 客户端，使用 10Mb 连接进行连接，结果仍然相似。

然后，我用带有 2 个 Xeon p4 的 pfSense 路由器替换了总部的 2950，突然发现 VPN 带宽大得多 - 使用我的家用电脑重新进行相同的测试，突然发现几乎接近可供我测试的全部 10 Mb 带宽。

我打算在工作台上用一些 2800/2820 来测试 2950，但是我看到 2950 被 pfSense 替换后有所改进，我认为继续使用 2950 毫无意义。28*0 的站点速度有所提升，但连接速度更快（超过 10Mb）的站点仍然无法充分利用 - 我怀疑这是由于 28*0 的限制。

经过进一步调查，我发现了一个从命令行对我的 pfSense 路由器进行基准测试的命令，该命令显示加密吞吐量会因数据包大小而有很大差异。我怀疑 2950 声称的 90Mb VPN 吞吐量使用了现实世界中从未见过的大量数据包，尽管公平地说，Draytek 并不是唯一一家犯有此类行为的供应商。如果你可以使用 iperf 更改数据包大小，那么看到差异我一点也不惊讶。

考虑过设备是否足够强大，能够以您希望的速度维持 VPN 隧道后，下一步就是在预算允许的情况下考虑 WAN 优化设备。Riverbed Technologies 和 Cisco 等公司生产的设备可以努力减少通过 VPN 发送的实际流量，同时不会对两端造成明显影响。

您还可以使用 Drayteks 尝试启用 vj 压缩来查看是否有帮助。

答案2

您需要在测试期间进行基准测试和监控，以找出瓶颈。

  • 在不启用任何 VPN 的情况下，通过相同链接在站点之间运行 iperf 测试。这将为您提供基准。

  • 你的 ping 往返时间是多少？你可能需要使用 iperf 的 -W 参数来增加 TCP 窗口大小，因为它默认为 8k 固定大小，这会限制除本地 LAN 之外的任何设备的吞吐量。阅读带宽延迟积。在正常运行中，现代操作系统会动态调整 TCP 窗口大小，但 iperf 会覆盖此行为并默认为 8K TCP 窗口。

  • 确保你不阻止 ICMP 数据包过大消息 无论是在 VPN 内部还是外部。您还必须确保路由器正确生成这些 ICMP 消息；它们对于 TCP 吞吐量至关重要。您的 DSL 和 IPsec 隧道本身都会将您可以处理的最大数据包大小限制为远小于 1500 字节。此外，请确保您没有在任何设备上设置不分段位来分段数据包。

  • 禁用任何链路负载平衡，只使用一条链路进行测试。根据具体实施，这些可能会导致数据包重新排序并降低 TCP 吞吐量。如果在一条链路上获得良好吞吐量后重新启用负载平衡，您可能只想在“源-目标 IP 对”上进行负载平衡（如果可以选择），不要选择“每个数据包负载平衡”。

  • 测试期间需要监控的事项：路由器看到的链路利用率、主机和路由器上的 CPU、每秒中断数、每秒数据包丢失数、接口错误（如果有）。

  • 我假设您的路由器在软件中执行所有 IPsec，并且没有加密卸载。因此，选择 AES-128 和 SHA-1 作为 IPsec 隧道的加密算法；与软件中的 3DES+SHA-1 相比，这些算法大约占用 20% 的 CPU。

  • 禁用路由器上的所有其他功能，例如 IDS/IPS 扫描、防病毒扫描、网络过滤等。这些功能可能会占用大量 CPU 或导致排队延迟。

  • 注意缓冲区膨胀，并根据观察到的 ping 时间将您可以配置的任何过大的路由器缓冲区减少到实际值。

  • 在下班后进行测试以确保您不会与正常流量发生冲突。

假设一切正常，当使用带有 AES-128 和 SHA-1 的 IPsec 时，您应该能够获得非 VPN 基线测试的 10-20％ 以内的效果。

答案3

几年后才读到这个。:) 原始问题看到的瓶颈来自 VPN 服务器所在的远程端的 512kbps 上传速度限制。

例如，如果您从笔记本电脑（无论您使用哪种 VPN 协议）连接到远程站点的 VPN，然后使用 speedtest.net 从笔记本电脑进行速度测试，则所有速度测试流量都会通过 VPN 隧道传输。由于远程系统在其一端的“上传”速度上限约为 512kbps，因此您在笔记本电脑一端看到的“下载”速度不会超过这个速度。对您来说，这是下载，但从远程站点来看，这是通过 VPN 隧道将流量上传到您的笔记本电脑。我们已经确定远程端的上传速度限制为 512kb。清楚吗？

如果获得 600kbps，您实际上会获得相当不错的速度，因为这高于远程站点的 512kbps 上传速率。

相关内容