☰

Linux 服务器在 Sonicwall 防火墙保护下下载性能不佳

tag-icon • tag-icon linux networking sonicwall
Linux 服务器在 Sonicwall 防火墙保护下下载性能不佳

我正在使用一对共置的 CentOS Linux 服务器，它们位于以透明桥接模式运行的 Sonicwall PRO 2040 增强型防火墙后面。

这些服务器在下载超过几兆字节的文件时会遇到一个奇怪的问题。例如，如果我尝试使用 wget 或 FTP 从 kernel.org 下载一份 Linux 内核副本，前 1-2MB 的下载速度将达到 600+K/s，然后吞吐量将急剧下降到 1K/s。

我检查了所有防火墙配置设置，看是否有任何可疑之处，但一无所获。更有趣的是，我在同一个防火墙后面的 Windows 服务器上执行了同样的下载，整个过程都以 600+K/s 的速度顺利通过。

有人见过这种情况吗？我应该从哪里开始解决此问题？

答案1

我们也遇到了同样的问题。任何大于初始下载突发传输量（我们约为 3.7mb）的数据，无论可用带宽是多少，都会以每秒约 1-4kb 的速度缓慢传输。

这似乎是 SonicWall PRO 2040 防火墙特有且常见的问题 -https://discussions.apple.com/message/12250946?messageID=12250946

问题的根源在于防火墙，而最好的长期解决办法是在防火墙上找到一个设置，允许打开“TCP 窗口缩放”选项，并在连接初始化时正确使用启动机器的 TCP 窗口缩放因子。

虽然本文涉及的是路由器，但同样的逻辑也适用于 SonicWall Pro 2040 防火墙的情况，http://lwn.net/Articles/92727/：

细节仍在研究之中，但似乎网络上的一些路由器在 SYN 数据包通过时重写了窗口缩放 TCP 选项。具体来说，它们似乎将缩放因子设置为零，但保留选项。接收方看到该选项，并使用自己的窗口缩放因子进行响应。此时，发起系统认为其缩放因子已被接受，并相应地缩放其窗口。然而，另一端认为缩放因子为零。结果是对接收窗口的实际大小产生误解，防火墙后面的系统认为它比实际小得多。如果预期的缩放因子（以及差异）很大，结果充其量是通信速度非常慢。在许多情况下，小窗口可能导致根本没有数据包传输，从而完全破坏两个受影响系统之间的 TCP。

与上面提到的类似，针对个别机器也有解决方法 -http://prowiki.isc.upenn.edu/wiki/TCP_tuning_for_broken_firewalls通过关闭 rfc1323 TCP 扩展，防火墙永远没有机会传递 TCP 窗口比例因子 0，而是传递 rfc1323 扩展未启用的信息，大概是使用没有 rfc1323 扩展的 TCP 允许的最大窗口大小，即 64kb。

我们在各种机器上使用的临时解决方法的命令：

Ubuntu 10.10：
更改立即生效：

sudo sysctl -w net.ipv4.tcp_window_scaling=0

下次重启后将发生永久更改：

sudo sh -c 'echo "net.ipv4.tcp_window_scaling=0" >> /etc/sysctl.conf'


Mac OSx：
更改立即生效：

sudo sysctl -w net.inet.tcp.rfc1323=0

下次重启后将发生永久更改：

sudo sh -c 'echo "net.inet.tcp.rfc1323=0" >> /etc/sysctl.conf'


Windows 7的：
查看可用选项：

netsh interface tcp show global

禁用命令（持久）：

netsh interface tcp set global autotuning=disabled


为了回答为什么 Windows Server 没有任何问题，我找到了这篇文章 -http://msdn.microsoft.com/en-us/library/ms819736.aspx

在 Windows Server 2003 中，TCP 窗口缩放是根据发起连接时为 SO_RCVBUF Windows 套接字选项设置的值按需协商的。此外，如果 TCP 对等方发起的连接的接收 SYN 段包含“窗口缩放”选项，则默认情况下在连接上使用“窗口缩放”选项。默认情况下，Windows Server 2003 TCP 不会使用窗口缩放发起连接。要指示 Windows Server 2003 TCP 堆栈尝试通过使用“窗口缩放”选项协商更大的接收窗口大小，请将 Tcp1323Opts 注册表值设置为 1。

答案2

如果您启用了入侵防御和/或防病毒功能，这些防火墙将陷入瘫痪。特别是如果您选择了 TCP 流作为要扫描的类型之一。它会尝试在内存中构建整个文件以进行扫描...
暂时禁用这些功能，看看您的性能是否会恢复。如果是这样，那么请考虑将您的服务器添加到例外列表中，这样您就不必为整个网络而大吃一惊。

答案3

您是否发现从网络内部下载到 Linux 服务器时存在问题？如果没有，那一定与 Linux 和防火墙的组合有关。在防火墙上，您可以查看 CPU 使用情况或查找警告吗？重置防火墙怎么样？

也许在第一个 MB 左右之后，Linux 会自动调整 TCP 选项（或者可能是第 2 层），而防火墙不喜欢这样？查看 /proc 中的各种网络选项可能会给你一个想法。此外，Linux 上的数据包转储可能会显示速度变慢时正在发生的变化。

答案4

尝试更改 Sonicwall 上的 TCP 窗口。

  1. 登录SonicWALL管理页面
  2. 将 URL 结尾从 main.html 更改为 diag.html
  3. 单击“内部设置”，转到“安全服务设置”
  4. 勾选“启用对任何基于 DPI 的服务允许的最大通告 TCP 窗口的限制”
  5. 请记住向上滚动页面并按“应用”！

相关内容