☰

Windows 10 使用错误的 NIC 访问某些 IP 地址

tag-icon • tag-icon routing windows-10 nic multi-homed
Windows 10 使用错误的 NIC 访问某些 IP 地址

我有两台运行 Windows 10 Enterprise 2016 LTSB 的服务器，它们似乎使用了错误的 NIC。

该网络由 2 个子网组成。因此，每台服务器在“主”网络上都有一个 NIC，可以访问 Internet，即 10.1.10.0/24。然后，每台服务器在没有 Internet 的“IoT”网络上都有另一个 NIC，即 192.168.2.0/24。主网络上的 NIC 使用 DHCP；IoT 网络上的 NIC 使用静态 IP 地址。IoT 子网是一种临时的。路由器对此并不“了解”。我只是将 IoT 设备和 IoT NIC 设置为使用不同的 IP 方案，但该子网的所有内容都与网络的其余部分位于同一个交换机中。

当然，我认为如果我 ping 物联网网络上的设备，Windows 将使用直接连接的 NIC。但情况并非总是如此。对于某些 IP 地址，Windows 将使用物联网 NIC，对于其他 IP 地址，Windows 将使用主 NIC。（我通过 WireShark 验证了正在使用哪个 NIC，但据记录，当我使用时，每次 ping 都会通过ping -S [address of the IoT NIC]。）

C:\Users\***>ping 192.168.2.102

Pinging 192.168.2.102 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.2.102:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\***>ping -S 192.168.2.10 192.168.2.102

Pinging 192.168.2.102 from 192.168.2.10 with 32 bytes of data:
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128
Reply from 192.168.2.102: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.2.102:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

真正奇怪的是，Windows 不使用相同的 NIC 与每个 IoT IP 地址通信。每次服务器重新启动时，它几乎就像盲目地抽签决定使用哪个 NIC 与每个地址通信，并且它将继续使用该 NIC 与该地址通信，直到下次服务器重新启动。

路由表如下。记住，192.168.2.0 是 IoT 网络，10.1.10.0 是主网络。

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.1.10.1      10.1.10.117     11
        10.1.10.0    255.255.255.0         On-link       10.1.10.117    257
      10.1.10.117  255.255.255.255         On-link       10.1.10.117    257
      10.1.10.255  255.255.255.255         On-link       10.1.10.117    257
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
      169.254.0.0    255.255.255.0         On-link       169.254.0.2    266
      169.254.0.2  255.255.255.255         On-link       169.254.0.2    266
    169.254.0.255  255.255.255.255         On-link       169.254.0.2    266
      192.168.2.0    255.255.255.0         On-link      192.168.2.10    266
     192.168.2.10  255.255.255.255         On-link      192.168.2.10    266
    192.168.2.255  255.255.255.255         On-link      192.168.2.10    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link       10.1.10.117    257
        224.0.0.0        240.0.0.0         On-link       169.254.0.2    266
        224.0.0.0        240.0.0.0         On-link      192.168.2.10    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link       10.1.10.117    257
  255.255.255.255  255.255.255.255         On-link       169.254.0.2    266
  255.255.255.255  255.255.255.255         On-link      192.168.2.10    266

以下是我目前已经研究过的几件事：

到目前为止，这些方法都没有给出答案。我尝试禁用 SMB MultiPath，但没有任何效果，即使重新启动服务器也是如此。更改指标似乎也没有任何作用。

此时，我最好的猜测是 Windows 正在后台进行一些负载平衡，以将流量发送到错误的 NIC。但是，如果到 192.168.2.0/24 的路由显然经过一个接口，它为什么要这样做呢？要清楚的是，连接到主 NIC 的路由器没有 192.168.2.0/24 的路由。

为什么 Windows 会选择错误的 NIC？我该如何修复它？

答案1

我也见过这种行为。在我的例子中，如果 192.168.2.102 不存在（没有 arp 响应），Windows 应该会显示“目标主机无法访问”或“请求超时”（不确定哪个更正确）。相反，它会通过另一个接口中的网关发送 ping 请求。我很想知道在发帖人的情况下不正确的 IP 地址是否出现在“arp -a”的输出中。

在某些网络中，这可能比其他网络更重要；例如，现在数据包内的数据应该内部的（您的 IoT LAN）可用于运行的任何数据包捕获外部的（您的“主”LAN）。这可能包括机密，使用 SNMP v2 时会这样做。我认为旧版本的 Windows 不会这样做，它基本上会忽略手动路由配置并尝试默认网关。

即使我添加了：route add 192.168.2.102 mask 255.255.255.255 192.168.2.10 metric 1 这个该死的东西仍然会从错误的接口发送数据包。

我希望我为某些人带来了一些价值。我现在确实从正确的接口获得了一个“无法到达目的地”的信息，然后 Windows 会通过此时使用另一个接口来“提供帮助”。

相关内容