☰

Windows 路由中最长前缀匹配的行为

tag-icon • tag-icon ip-routing windows-11
Windows 路由中最长前缀匹配的行为

描述

我遇到了最长前缀匹配不发生的情况。

设置

在我的实验室机器上，我有一个虚拟网卡 VMnet11 (VMWare)，其 IP 地址为 181.0.0.10/8。我有一个物理网卡，其 IP 地址为 192.168.4.110/24，它将流量路由到 192.168.4.84 作为默认网关（可以访问互联网）。

问题

尽管指标相同（291），但当我 ping 181.0.0.1 时，流量通过默认网关路由到互联网（匹配 0.0.0.0 前缀），而不是通过 VMnet11 尝试流量。 （255.0.0.0 前缀不匹配）

笔记 对 181.0.0.10（本地分配给 VMnet11 的 IP）执行 ping 操作时，观察到正确的行为。（即 255.255.255.255 前缀与本地接口匹配）

输出

以下是“路线打印”的相关部分：

===========================================================================
Interface List
 26...00 e0 4c 62 16 05 ......Realtek RTL8139/810x Family Fast Ethernet NIC
  7...00 50 56 c0 00 0b ......VMware Virtual Ethernet Adapter for VMnet11

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.4.84    192.168.4.110    291
        181.0.0.0        255.0.0.0         On-link        181.0.0.10    291
       181.0.0.10  255.255.255.255         On-link        181.0.0.10    291
  255.255.255.255  255.255.255.255         On-link        181.0.0.10    291

===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
          0.0.0.0          0.0.0.0     192.168.4.84  Default
===========================================================================

以下是“ipconfig”的相关输出：

C:\Users\user>ipconfig
Ethernet adapter PCI:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.4.110
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.4.84

Ethernet adapter VMware Network Adapter VMnet11:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::a2e7:a501:ffd5:ccac%7
   IPv4 Address. . . . . . . . . . . : 181.0.0.10
   Subnet Mask . . . . . . . . . . . : 255.0.0.0
   Default Gateway . . . . . . . . . :

以下是“traceroute”的相关输出：

C:\Users\user>tracert -d  181.0.0.1

Tracing route to 181.0.0.1 over a maximum of 30 hops

  1    <1 ms     1 ms    <1 ms  192.168.4.84
  2     1 ms     1 ms    <1 ms  <public ip>
  ...

问题

什么原因阻止了最长前缀匹配的发生？

更新

reddit 链接信息量很大（谢谢）。提到 ARP 也很有用（谢谢）。

我现在怀疑这是微软（设计上的）问题（在 ARP 未命中时恢复为 def gw，这不是路由器的预期行为，这就是为什么 reddit 人称微软的操作系统是更差的路由器）。下面找到一些 ping 和 ARP 的更多输出。

这是我 ping 181.0.0.2 时预期会发生的情况

C:\Users\user>ping 181.0.0.2

Pinging 181.0.0.2 with 32 bytes of data:
Reply from 181.0.0.10: Destination host unreachable.
Request timed out.
Request timed out.

但是，这是固定 181.0.0.1 时发生的不良行为：

C:\Users\user>ping 181.0.0.1

Pinging 181.0.0.1 with 32 bytes of data:
Reply from 181.0.0.1: bytes=32 time=478ms TTL=43
Reply from 181.0.0.1: bytes=32 time=454ms TTL=43

没有arp条目

C:\Users\user>arp -a 181.0.0.1
No ARP Entries Found.

C:\Users\user>arp -a 181.0.0.2
No ARP Entries Found.

（显然这样的 IP 在我的实验室网络上不存在，并且我期望通过 icmp 响应得到回应）

答案1

由于 Vista 中重写了 IP 堆栈以提供 IPv4 和 IPv6 之间的功能奇偶校验，因此 Windows 对 IPv4 和 IPv6 都使用 RFC 3484。

您在此处看到的问题可能是由于源地址选择造成的。由于您自己不提供源地址，因此系统需要选择一个。在 IPv4 中，这应该始终选择与属于从最长前缀匹配确定的路由的接口匹配的地址。但是，在 RFC 3484 第 5 节（“源地址选择”）末尾附近有以下段落：

Rule 8 may be superseded if the implementation has other means of
choosing among source addresses.  For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.

（规则8为最长前缀匹配）

由于邻居发现（或 IPv4 中所说的 ARP）对目标地址失败，路由器知道直接联系将失败。因此默认路由是最佳匹配，其关联接口的地址将用作源地址。

ping在您的情况下，如果您使用提供源地址-s，那么这应该会否决源地址选择，因此不应尝试默认路由。

（抱歉，我几乎没有参考资料，但由于这种变化发生在大约 15 年前，很难找到具有合理可信度的文章）

相关内容