主页 / server / 问题 / 64232
Accepted
Geoff Dalgas
Asked: 2009-09-11 09:38:43 +0800 CST

Windows 2008 Server 上的死网关检测

  • 772

我们最近为 stackoverflow.com 实现了 HAProxy。我们决定使用 TProxy 来维护客户端连接的源地址，这样我们的日志和其他依赖于客户端 IP 地址的 IIS 模块就不需要修改。因此，数据包以欺骗方式到达，就好像它们来自外部互联网 IP 地址一样，而实际上它们来自我们本地网络上的本地 192.168.xx HAProxy IP。

我们的两个 Web 服务器都有两个 NIC——一个在公共互联网上具有静态 IP、DNS 和默认网关的可路由 B 类地址，另一个配置了指向 HAProxy 专用 IP 的默认网关的私有不可路由 C 类地址。HAProxy 有两个接口——一个是公共的，一个是私有的，负责在接口之间透明地路由数据包并将流量引导到适当的 Web 服务器。

以太网适配器 Internet：

   描述 。. . . . . . . . . . : 网卡#1
   启用 DHCP。. . . . . . . . . . ： 不
   启用自动配置。. . . ： 是的
   IPv4 地址。. . . . . . . . . . : 69.59.196.217 (首选)
   子网掩码 。. . . . . . . . . . : 255.255.255.240
   默认网关 。. . . . . . . . : 69.59.196.209
   DNS 服务器。. . . . . . . . . . : 208.67.222.222
                                       208.67.220.220
   通过 Tcpip 的 NetBIOS。. . . . . . . : 启用

以太网适配器专用本地：

   描述 。. . . . . . . . . . : 网卡#2
   启用 DHCP。. . . . . . . . . . ： 不
   启用自动配置。. . . ： 是的
   IPv4 地址。. . . . . . . . . . ：192.168.0.2（首选）
   子网掩码 。. . . . . . . . . . : 255.255.255.0
   默认网关 。. . . . . . . . : 192.168.0.50
   通过 Tcpip 的 NetBIOS。. . . . . . . : 启用

我们在每个 Web 服务器上禁用了自动指标，并为可路由的公共类 B 分配了 10 的指标，我们的私有接口分配了 20 的指标。

我们还设置了这两个注册表项：

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DeadGWDetectDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableDeadGWDetect"=dword:00000000

我们每天大约会看到两次问题，其中一个 Web 服务器无法联系 DNS 或无法连接到公共互联网上的任何其他服务器。

我们怀疑死网关检测错误地检测到公共网关上的中断，并将所有流量切换到此时没有 DNS 访问但无法验证这一点的私有网关。

  1. 有没有办法知道死网关检测是否正在运行，甚至是 Windows 2008 服务器中的一个选项？

  2. 如果是这样，有没有办法在 Windows 2008 服务器中禁用死网关检测？

  3. 如果不是，是否还有其他原因导致我们无法解析 DNS 或在短时间内无法连接？

windows-server-2008

4 个回答

  1. 那些死网关检测 DWORD 在 Windows Server 2008 上毫无用处。它们存在的唯一原因是出于兼容性原因。TCP/IP 驱动程序和 Windows 路由器组件不再查找这些值。

    我怀疑这个功能被引入了自动调整，它在 Windows Vista 中首次亮相。尝试在提升的命令提示符下执行以下命令（并重新启动）：

    netsh int tcp 设置全局 autotuninglevel=disabled


    更新（添加于 2009 年 9 月 13 日 @7:58PM EST）

    如果这不起作用，我们将需要更多的诊断输出。使用 NetConnection 或 LAN 方案启动（循环）跟踪，并让它继续运行，直到出现问题。

    netsh 跟踪启动方案=NetConnection maxSize=512

    （示例：启动 NetConnection 跟踪场景，最大跟踪日志大小为 512MB）

    您可以在Network Monitor 3.3中打开生成的跟踪，只需确保安装了最新的解析器。

    • 5
  2. Best Answer

    我们无法得出关于为什么我们无法控制死网关检测行为的结论性结果。

    我们没有花费大量时间来解决这个问题，而是选择让我们的 HAProxy 实例将流量路由到出站网关，并将两个 Web 服务器的默认网关设置为 haproxy 的 IP，并删除了内部网关地址。 

      [ soweb1 ] 69.59.196.220, GW=69.59.196.211 [haproxy]
       |
       +---- [haproxy] 69.59.196.211, GW 69.59.196.209
       |
    [ gw ] 69.59.196.209

    现在只有一个默认网关可以消除我们的问题，因为不再使用死默认网关检测。

    • 5

  3. 我会质疑为什么您甚至需要将默认网关更改为 HAproxy。通常，您根本不应该更改默认网关，除非您将其指向高度可用的 N+1 设置，在该设置中，网关 IP 可以在发生不良情况时故障转移到另一台路由器/机器。如果您的 HAproxy 机器出现问题并且您没有任何带外访问权限，那么 Web 服务器将直接断开 Internet。

    我相信您这样做的原因可能是因为您在设置中使用 Tproxy 使客户端 IP 地址出现在您的日志中，而不是代理服务器的 IP，我可以建议您改为这样做吗

    1. 将“option forwardfor ...”添加到您的 HAproxy 配置中
    2. 安装x-forwarded-for ISAPI 过滤器
    3. 从您的设置中删除 tproxy
    4. 通过直接连接互联网将默认网关更改回您之前使用的相同网关

    我没有 Windows 机器来测试它，但我相信它应该会产生预期的效果，而不会出现不希望的连接丢失。

    • 4

  4. 当涉及到 Internet 访问时（通常），那么默认网关应该只用于表示到 INTERNET 的路径。如果您定义了多个默认网关，则操作系统路由器无法决定使用哪一个，并且如果一个默认网关指向死胡同（例如您的多段 LAN），那么转发到互联网的数据包是不会成功的。

    • -1

相关问题